similar to: [PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)

Thanks, that worked like a charm except for the following: llvm generate: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* align 1 bitcast ([512 x float] addrspace(3)* @a_scratchpad to i8 addrspace(3)*), i8 addrspace(1)* align 1 %0, i64 2048, i1 false) And we expected: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8

Yes, all that is correct. My question is more a long term question: why do the .ll printer specify the alignment if it is equivalent to the default one? That is, it seems the sed script expect the printer to not specify it (this would match the load/store behavior), but the ll-printer does specify it, which either means the printer is not ideal on this case and I should fix it, or in this case

Hi Alexandre, The script uses extended-sed syntax, so you need to run sed with the -E option. For example, when preparing the patch I created a file ( script.sed ) containing all of the lines that I copied into the commit message. Then, I ran this bash one-liner from the test directory: for f in $(find . -name '*.ll'); do sed -E -i ‘.sedbak' -f script.sed $f; done When I was happy

Good question. AFAIK, the IR-printer doesn’t understand the semantics of parameter attributes. In this case, it only knows that there is an attribute on the parameter that is integer valued (with value 1) and that has the name “align”, so it prints it out. If we don’t want it printing out ‘align 1’ then it’s up to us to not set the alignment parameter attribute to a value if that value would be 1.

Hi Alexandre, Before the change you would have been expecting one of the following, correct? a) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8 addrspace(1)* [[APTR]], i64 2048, i32 0, i1 false) b) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8

Hello, I was trying to compile a simple program with the CppBackend like so: $ clang str_arg.c -emit-llvm -S $ llc -march=cpp str_arg.ll It produces a file `str_arg.cpp` as expected, however it doesn't seem that the resulting file is correct. For once, it includes `<llvm/Analysis/Verifier.h>` which seems to have been moved to `llvm/IR/Verifier.h` as far back as 2013. My question is

Yes, it's quite obviously dead and should be deleted. When I brought this up last time -- after realizing that it wasn't actually a backend that targetted c++ (which might be useful), but rather just something that emitted IR by calling llvm C++ functions (which really isn't IMO) -- someone also pointed out that it also really ought to be using IRBuilder...if anyone cared about it.

> after realizing that it wasn't actually a backend that targetted c++ > (which might be useful) Exact same thing just happened to me.. it's not obvious, especially when reading the llc info: $ llc -version Registered Targets: arm - ARM arm64 - ARM64 (little endian) cpp - C++ backend x86 - 32-bit X86: Pentium-Pro and above x86-64

Hello. Excuse me. Why CMakeLists.txt from llvm-3.9.1.src does not contain WebAssembly target? So, it is like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ X86 XCore ) but not like set(LLVM_ALL_TARGETS AArch64 AMDGPU ARM BPF Hexagon Mips MSP430 NVPTX PowerPC Sparc SystemZ Webassembly X86

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As an update, after lots of fixes from a number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM ::

On Tue, Feb 9, 2016 at 11:01 PM, Pete Cooper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Feb 9, 2016, at 10:24 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > You've raised an important point here Pete, and while I disagree pretty > strongly with it (regardless of whether Lanai makes sense or not), I'm glad > that you've

On Thu, Jun 4, 2015 at 5:51 AM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > Author: dsanders > Date: Thu Jun 4 07:51:20 2015 > New Revision: 239035 > > Include BPF target in CMake builds. > > Modified: > llvm/trunk/CMakeLists.txt > > --- llvm/trunk/CMakeLists.txt (original) > +++ llvm/trunk/CMakeLists.txt Thu Jun 4 07:51:20 2015 > @@

Matt: that’s fair. We’re generally apprehensive of option 2 as well. Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader. If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify

I'd like to (re)start a discussion on a few gotchas in FileCheck that I've noticed working on various tests in llvm's suites. This begain in a review [1], but I'll try to summarize here so it gets the right audience before decisions are made on it (so to speak). 1: https://reviews.llvm.org/D77227 The main sticking point is the abundance of checks in FileCheck tests that appear to

After some head scratching and debugging it turns out that disabling shared libs fixes the problem. This might be related to http://llvm.org/bugs/show_bug.cgi?id=13124 . It would be nice to get this finally fixed otherwise cmake + shared libs is no go. Thanks. On Mon, Aug 5, 2013 at 11:54 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > I am building llvm 3.3 with cmake

On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Presumably if my out-of-tree backend was to be pushed to LLVM, it too would be considered experimental. Yes. Though, not all out-of-tree back-ends end up upstream for different reasons. A few basic rules to get accepted are if: * the target exists and can be easily purchased / emulated

> From: Krzysztof Parzyszek [kparzysz at codeaurora.org] > On 3/4/2015 10:30 AM, Daniel Sanders wrote: > > > > Partial support for ZC is in my working copy at the moment. I've attached my WIP patches. > > Should have guessed that, ha. > > I've looked into this. My idea was to expand the single address operand > of the inline-asm SDNode into two: base