[llvmlinux] Etherpad notes from LPC

Renato Golin renato.golin at linaro.org
Fri Sep 20 21:50:56 UTC 2013


Hi Mark,

Lots of gems in here! I think this could become an LLVM Blog post... Can
you write something?

cheers,
--renato

PS: Apple didn't write the ARM64 back-end, Tim Northover from ARM did
(single-handed). He's now at Apple, but not at the time.


On 20 September 2013 22:13, Mark Charlebois <charlebm at gmail.com> wrote:

> *Here are the notes from the LPC LLVM Microconference:*
> *
> *
> *Linux Plumbers Conference 2013*
> *LLVM Microconference*
>
> 1. The unified x86 tree and clang
>
> Question: What assember is being used
> Answer: Not using IA, using gas
>
> Question: Why does clang need to be updated so it can guess the length if
> using gas
> Answer: clang is creating the assembly from the inline assembly
>
> Comment from Linus: (Linux) Did not want to overspecify things and
> generate worse code - LLVM fixed the issue
>
> Current aproach to working around named registers adds a move, push and
> pop. Will likely need to add the ability to clang to get the SP directly
> for an optimal solution
>
> Question: Have you tried to build with ALL options on?
> Answer: llvmlinux website shows the broken kernel options
>
> Question: Are all the issues in assembly or are they in C code as well
> Answer: There are issues in C as well: order of declaration of attributes,
> VLAIS, use of builtin_constant_p, explicit register variables, etc
>
> Question: Where are the kernel patches that are required at the moment?
> git://git.linuxfoundation.org/llvmlinux/kernel.git ?
>
> 2. Using the Clang Inegrated Assembler to Compile the Linux Kernel
>
> Need to investigate whether ambiguous inline x86 assembly issues is fixed
> or not
>
> Comment from Linus: Clang can be fixed because bit operations have known
> semantics unlike the add case
>
> Question: What about on big endian? Bit ops may need to be explicitly
> specified
> Answer (Linus): Yes, it would have to be explicitly specified
>
>
>
> 3. Variable Length Array's in Structs (VLAIS)
>
> Question: What about flexible arrays.
> Answer: They're supported, but only at the end of the structure.
> Netfilter code uses them at different places extensively, needs to be fixed
>
> Suggestion: Enable separate warning for this case.
>
> Question: For certain archs char sdesc needs to be aligned.
> Answer:  CRYPTO_MINALIGN_ATTR is used.
>
> Q: Do you allow VLA outside of the struct.
> A: That's what we did in one of the patches.
>
> Q: Netfilter: why not move "term" up and make it a flexible member.
> A: Unfortunately the placement of "term" is a userspace thing.
> Linus: Oh, that's bad! Let's fix netfilter!
>
>
> Note: use of this constructs is spreading (c'n'p)
> - Bluetooth, Filesystems and so on.
>
> Configfs / Gadget :  Gadget developer liked patch - going to take it.
>
> Q: Sounds like convincing gcc ppl to accept a warning - what about sparse ?
> A: Sparse chokes on it atm.
>
> Note: Argument for gcc: as it is not supported - create a warning.
>
>
>
> 4.  Compiling Android Userland with clang
>
> Comment (Bryce): Using -std=C++11 is preferable
> Response (Bero): Want to balance correctness with upstreamability
>
> Comment: C++14 add support for variable length arrays of non-POD elements,
> should keep the code as is
>
> Look at whether clang has issues complaining about uninitialized variables
> after no-return paths (i.e. abort)
>
> Question (Zach): Can clang built libs work with gcc built libs?
> Answer: Yes, done in std android with libpng
> Comment (Bryce): Can be an issue with Glibc
>
> Bero: GCC 4.8 can compile libc++, but app using it will crash on locale
>  facets
>
>
> 5. Building the Linux Kernel and User space for the Hexagon DSP with LLVM
>
> Question (Zach): Why use LLVM vs GCC
> Answer (Anshu): Can add optimizations for customers months sooner than
> could be done with GCC
> Comments (Bill): If you are going to support a new achitecture today,
> LLVM/clang is the best choice. DSP devs are more interested in becoming
> experts in LLVM vs other compiler code bases
>
> Question (Pavel): What tests can/should be used to compare performance
> with different flags, compiler, etc. Usually people run some benchmark tests
> Answer (Zach): Try Michael Hope (now at Google)
>
> Comment (Bill): Linaro has LAVA to track performance over time. Yocto
> project is also looking at test infrastructure
>
> Question: Where is the best place for info to get started working on LLVM
> (for a new arch)
> Answer (Bryce): Mailing list, look at what Apple did for ARM 64bit
> Answer (Anshu): Oly took a few weeks to get up and running, look at
> Hexagon implementation upstream
>
>
>
> 6. Rebuilding debian with LLVM/Clang
>
> -Werror - use wrapper and  -Werror -Wno-error=foo
>
> Q: Are the packages all built with clang (or perl/python)
> A: there's no way to differ the compiler or perl/python is used. Thus the
> number is all packages.
>
> Q: Do you install the build-results into the build-chroot ?
> A: not yet.
>
>
> 7. Linux and the LLVM Static Analyzer
>
> Comment: Something desirable from llvm tools would be a scan-build like
> browser for looking at the registered handlers for the kernel driver
> interfaces
>
> Comment: Documentation (on how to use scan-build) would be really helpful
>
> Question: How do you invoke scan-build
> Answer (Eduard): More or less "scan-build make ..."
>
> Question: C interface for the checkers?
> Answer: Not likely
>
> Question: Seems that you have to use the same compiler to create the
> checkers as to build scan-build/llvm?
> Answer (Bryce): Is doing something similar to what clang is doing and it
> does work across Linux and Windows
>
> For scan-build you need a newer version of clang than the pre-packaged
> version on llvm.org
>
>
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130920/031bef99/attachment-0001.html>


More information about the LLVMLinux mailing list