similar to: [LLVMdev] Flag output used by two other nodes in DAG

Hello, Edmund, > Is it, or should it be legal for a Flag output to be used as input by > more than one other node? It's illegal. Multiple uses of the flag output do not make any sense, this breaks the semantics of flag operands. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Anton Korobeynikov: > > Is it, or should it be legal for a Flag output to be used as input by > > more than one other node? > It's illegal. Multiple uses of the flag output do not make any sense, > this breaks the semantics of flag operands. All right. Then what should the Selection DAG look like in a case where the flag value generated by one instruction is to be used as

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

Hi Rafael, > I am trying to add support for select_cc. In ARM it can be implemented > with: > > mov $dst, $falseVal > cmp $a, $b > moveq $dst, $trueVal The more normal ARM code, as produced by assembly writers and compilers that I've seen, is cmp $a, $b moveq $dst, $trueVal movne $dst, $falseVal e.g. at the end of a function returning r0 orr r0, r0, #0x40

Hi all, Consider this ARM assembly code of a C function: 00008124 <foo>: 8124: push {r4, r6, r7, lr} 8126: add r7, sp, #8 8128: mov r4, r0 812a: ldrsb.w r0, [r2] 812e: cmp r0, #1 8130: itt lt 8132: movlt r0, #85 ;

As Adrian said, we'd need to see the source of foo() to assess what the location-list for bar ought to be. Without actually going to look, I would guess that 'poplt' is considered a conditional move, therefore r4's contents are not guaranteed after it executes (i.e. it is a clobber). If one operand of 'poplt' is 'pc' then of course it is also a conditional indirect

Hello, Has anyone taken a look at this bug? I really want to fix this, but as Paul pointed out, this requires a lot of care... Thank you for your help Son Tuan Vu On Fri, Apr 27, 2018 at 7:29 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > Thank you all for taking a look at this. I pasted the C source then > deleted it because I was afraid that it was too long to read...

> On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi all, > > Consider this ARM assembly code of a C function: > > 00008124 <foo>: > 8124: push {r4, r6, r7, lr} > 8126: add r7, sp, #8 > 8128: mov r4, r0 > 812a: ldrsb.w

I am currently trying to compile a pretty simple program to work on an experimental board. It contains an (FPGA-version of) an ARMv4 processor. So basically, I try this (on my Ubuntu 18.04.1 LTS): clang -v --target=arm-none-eabi -c barehello.c -o barehelloCLANG.o clang -v --target=arm-none-eabi -c io.c -o io.o clang -v --target=arm-none-eabi barehelloCLANG.o io.o -o helloCLANGstatic -static

Hello, on the problems cross-building compiler-rt: Tried to follow https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html which lead to this cmake: cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF

Thank you all for taking a look at this. I pasted the C source then deleted it because I was afraid that it was too long to read... Here's the code of *foo*. Its real name is *verifyPIN*. The variable *bar* is *userPin*. int *verifyPIN*(char **userPin*, char *cardPin, int *cpt) { int i; int status; int diff; if (*cpt > 0) { status = 0x55; diff = 0x55; for (i = 0; i

<div dir='rtl'><div> <div dir="rtl"> <div dir="ltr">Could be... But the wierd thing here is if I change the array to be of size 256 and the index to be 'unsigned char', seems like there is no way to access the 'size' field throught "y->ptr[index]" (in your example) but clang still performs the re-read: <a

Hello LLVM, If there are any, can someone please explain rules of thumb for when to do a PerformDAGCombine operation in ISelLowering vs. when to do a DAG to DAG transformation? I'm specifically thinking of an AND + SRL merge into a bit field extract type instruction. I see that the ARM target does this in DAG-to-DAG, but this is literally a combine of two instructions,so why not DAGCombine?

Could you file a bug report about this (bugs.llvm.org <http://bugs.llvm.org/>)? If you don't have an account on bugzilla, I'd be happy to file one for you. Please provide exact instructions to reproduce the issue including any compilation flags. thanks, vedant > On May 7, 2018, at 9:16 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hello, > > Has

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >

Hello Christian, I'd expect that adding the library paths (-L) from gcc -v should fix the unable to find -lc, -lm but it won't fix the -lclang_rt.builtins-armv6m.a . To get clang_rt.builtins-armv6m.a you will need to cross compile compiler-rt for v6m and copy it to /usr/local/myclang/lib/clang/8.0.0/lib/baremetal . Beware that building compiler-rt for v6m does need quite a bit of fighting

Hello Christian, I reran my script with a similar cmake command to yours. After the build finished the following command from the build directory gave me: find . -name \*builtins.a ./lib/clang/9.0.0/armv6m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7em-none-eabi/lib/libclang_rt.builtins.a I hope you see something like