search for: vectorcall

Adding Support For Vectorcall Calling Convention ===================================================== Vectorcall Calling Convention for x64 ---------------------------------------------------- The __vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible. __vectorcall u...

...ARM and PPC support has been added to the `update_llc_test_checks.py` script. [r290144](http://reviews.llvm.org/rL290144), [r290370](http://reviews.llvm.org/rL290370). * The GlobPattern class has been imported into LLVM from LLD. [r290212](http://reviews.llvm.org/rL290212). * Codegen for the x86 vectorcall calling convention has landed. [r290240](http://reviews.llvm.org/rL290240). ## Clang commits * It is now possible to use the (still experimental) new pass manager with Clang. [r290450](http://reviews.llvm.org/rL290450). * The `alloc_size` attribute has been introduced. This allows the number of...

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In

...llvm/trunk/test/CodeGen/X86/tlv-1.ll > llvm/trunk/test/CodeGen/X86/unaligned-load.ll > llvm/trunk/test/CodeGen/X86/unused_stackslots.ll > llvm/trunk/test/CodeGen/X86/unwindraise.ll > llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll > llvm/trunk/test/CodeGen/X86/vectorcall.ll > llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll > llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll > llvm/trunk/test/CodeGen/XCore/memcpy.ll > llvm/trunk/test/DebugInfo/AArch64/frameindices.ll > llvm/trunk/test/DebugInfo/COFF/types-array.ll > llvm/trun...

...ailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/X86/tlv-1.ll llvm/trunk/test/CodeGen/X86/unaligned-load.ll llvm/trunk/test/CodeGen/X86/unused_stackslots.ll llvm/trunk/test/CodeGen/X86/unwindraise.ll llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll llvm/trunk/test/CodeGen/X86/vectorcall.ll llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll llvm/trunk/test/CodeGen/XCore/memcpy.ll llvm/trunk/test/DebugInfo/AArch64/frameindices.ll llvm/trunk/test/DebugInfo/COFF/types-array.ll llvm/trunk/test/DebugInfo/Generic/2010-...

...th change *after* these vector calculations and optimization passes are not aware of the impact of the vector length change on those calculations. Crucially, the vector length changes when calling and returning from functions in most calling conventions. Functions that don't specifically use a vectorcall ABI configure the vector unit for their own use when called, rather than using configuration set up by the caller. Therefore, caller and callee will generally have different vector lengths, and moving vector operations from the caller into the callee or vice versa tends to break programs. However,...

...odeGen/X86/tlv-1.ll >> llvm/trunk/test/CodeGen/X86/unaligned-load.ll >> llvm/trunk/test/CodeGen/X86/unused_stackslots.ll >> llvm/trunk/test/CodeGen/X86/unwindraise.ll >> llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll >> llvm/trunk/test/CodeGen/X86/vectorcall.ll >> llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll >> llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll >> llvm/trunk/test/CodeGen/XCore/memcpy.ll >> llvm/trunk/test/DebugInfo/AArch64/frameindices.ll >> llvm/trunk/test/DebugInfo/COFF/types-array...

...r calculations and optimization > passes are not aware of the impact of the vector length change on those > calculations. > > Crucially, the vector length changes when calling and returning from > functions in most calling conventions. Functions that don't specifically > use a vectorcall ABI configure the vector unit for their own use when > called, rather than using configuration set up by the caller. Therefore, > caller and callee will generally have different vector lengths, and moving > vector operations from the caller into the callee or vice versa tends to > break...

...>>> llvm/trunk/test/CodeGen/X86/unaligned-load.ll >>> llvm/trunk/test/CodeGen/X86/unused_stackslots.ll >>> llvm/trunk/test/CodeGen/X86/unwindraise.ll >>> llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll >>> llvm/trunk/test/CodeGen/X86/vectorcall.ll >>> llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll >>> llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll >>> llvm/trunk/test/CodeGen/XCore/memcpy.ll >>> llvm/trunk/test/DebugInfo/AArch64/frameindices.ll >>> llvm/trunk/test/DebugI...

...ailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/X86/tlv-1.ll llvm/trunk/test/CodeGen/X86/unaligned-load.ll llvm/trunk/test/CodeGen/X86/unused_stackslots.ll llvm/trunk/test/CodeGen/X86/unwindraise.ll llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll llvm/trunk/test/CodeGen/X86/vectorcall.ll llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll llvm/trunk/test/CodeGen/XCore/memcpy.ll llvm/trunk/test/DebugInfo/AArch64/frameindices.ll llvm/trunk/test/DebugInfo/COFF/types-array.ll llvm/trunk/test/DebugInfo/Generic/2010-...

...ailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/X86/tlv-1.ll llvm/trunk/test/CodeGen/X86/unaligned-load.ll llvm/trunk/test/CodeGen/X86/unused_stackslots.ll llvm/trunk/test/CodeGen/X86/unwindraise.ll llvm/trunk/test/CodeGen/X86/variable-sized-darwin-bzero.ll llvm/trunk/test/CodeGen/X86/vectorcall.ll llvm/trunk/test/CodeGen/X86/x86-64-static-relo-movl.ll llvm/trunk/test/CodeGen/X86/x86-repmov-copy-eflags.ll llvm/trunk/test/CodeGen/XCore/memcpy.ll llvm/trunk/test/DebugInfo/AArch64/frameindices.ll llvm/trunk/test/DebugInfo/COFF/types-array.ll llvm/trunk/test/DebugInfo/Generic/2010-...

...ization passes are not aware of the impact of >> the vector length change on those calculations. >> >> Crucially, the vector length changes when calling and returning from >> functions in most calling conventions. Functions that don't specifically >> use a vectorcall ABI configure the vector unit for their own use when >> called, rather than using configuration set up >> by the caller. Therefore, caller and callee will generally have >> different vector lengths, and moving vector operations from the caller into >> the callee or vice...

...*after* these vector calculations and optimization passes are not aware of the impact of the vector length change on those calculations. Crucially, the vector length changes when calling and returning from functions in most calling conventions. Functions that don't specifically use a vectorcall ABI configure the vector unit for their own use when called, rather than using configuration set up by the caller. Therefore, caller and callee will generally have different vector lengths, and moving vector operations from the caller into the callee or vice versa tends to break programs....

The 3.6 release is drawing nearer, but the release notes could still use a lot of improvement: LLVM: https://github.com/llvm-mirror/llvm/blob/release_36/docs/ReleaseNotes.rst Clang: https://github.com/llvm-mirror/clang/blob/release_36/docs/ReleaseNotes.rst The good news is that they can be updated all the way up until release. If you have a patch for the release notes, commit it directly to the