similar to: [LLVMdev] introducing sign extending halfword loads into the LLVM IR

done, bug 15057, hope I submitted it correctly ... On 23 Jan 2013, at 22:29, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > Hi Bjorn, > > could you file a bug on llvm.org/bugs and cc me on it. > > Thanks, > Arnold > > >> So it appears that also the ARM backend has a big problems with sign-extending loads. >> >> I've compiled the

On Jan 21, 2013, at 6:34 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > > On Mon, Jan 21, 2013 at 9:16 AM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > On 21 Jan 2013, at 14:39, Justin Holewinski <justin.holewinski at gmail.com> wrote: > >> Instruction selection happens on a different IR: SelectionDAG. In this IR, there are

> You're misreading the asm... nothing is touching memory. (BTW, "leal > -1(%eax), %eax" isn't a memory operation; it's just subtracting one > from %eax.) You might want to try reading the LLVM IR (which you can > generate with llvm-gcc -S -emit-llvm); it tends to be easier to read. I tried that, but I'm still learning LLVM. Seeing indvar, phi nodes, tail

Hi all, I've taken preglows ARM versions of qmf_synth and iir_mem16 from rockboxes speex codec, and tweaked them a bit further for some more speed. I attach them here so you can review and take on any changes you want. Please let me know if you have questions etc. Thanks, Robin -- Robin Watts, Email: <mailto:Robin.Watts@wss.co.uk> Warm Silence Software, WWW:

Hello, some of the patches had conflicts with LLVM head, so I updated them. If you experienced patch failure before then you can try it again. I compiled your code (1.c) with LLVM r308173 with the 5 patches applied, and it generated assembly like this. Now it contains store to c(%rip). It tries to store a(%rip) + b(%rip) to c(%rip). I wish this translation is now correct. ``` 73 .globl hoo

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?

Hi, On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi <wmi at google.com> wrote: >> >> It seems MemorySSA.cpp is the only real code where we found the >> problem happening. > > > This is doubtful, ¸FWIW :) > >> >> Is it possible to change the

On Mon, Jul 17, 2017 at 5:11 PM, Wei Mi <wmi at google.com> wrote: > On Mon, Jul 17, 2017 at 2:09 PM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: >> Hi, >> >> On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi

On 07/18/2017 06:03 PM, David Majnemer via llvm-dev wrote: > I doubt it is possible for us to try and make any fix which is > predicated on eagerly treating undef in a particular way, refinement > will always cause these problems to come about... > > Given what I've seen in LLVM (and what I've learned from other > compilers), we probably have two choices: > 1.

On Mon, Mar 2, 2009 at 2:45 PM, Jonathan Turner <probata at hotmail.com> wrote: > For which version of gcc?  I should mention I'm on OS X and using the LLVM > SVN. gcc 4.3. It's also possible this is processor-sensitive. >> First, try looking at the generated code... the code LLVM generates is >> probably not what you're expecting. I'm getting the

> Date: Mon, 2 Mar 2009 13:41:45 -0800 > From: eli.friedman at gmail.com > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Tight overlapping loops and performance > > Hmm, on my computer, I get around 2.5 seconds with both gcc -O3 and > llvm-gcc -O3 (using llvm-gcc from svn). Not sure what you're doing > differently; I wouldn't be surprised if it's

On 12/13/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Did you test what happens if you only enable arm4 assembly? Sure. I tested with "--enable-arm4-asm" and there was no difference. > Also, if you can do some investigation, it would be useful to check what bit > of assembly is causing the crash. Can you disable one at a time and check? ok. I'll try

Hi Warren, You have the -m32 flag set, but it's still giving you this: > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. But are you sure you want to compile the LLVM-GCC source? You should use the binaries unless absolutely necessary. -bw On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > Hi all,

This is a bug found by internal compiler bootstrap, and possibly it is the root cause of https://bugs.llvm.org/show_bug.cgi?id=33652 and https://bugs.llvm.org/show_bug.cgi?id=33626. Here is the testcase 1.c. The original code is at MemorySSA.cpp:586 for rL307764. ------------------------- 1.c --------------------------- long a, c, d, e, f, m, cnt, i_hasval; volatile long b; void goo(long); void

On Mon, Jul 17, 2017 at 11:18 AM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Mon, Jul 17, 2017 at 10:32 AM, Xinliang David Li <davidxl at google.com> > wrote: > > The issue blocks another optimization patch and Wei has spent huge > amount of > > effort isolating the the bootstrap failure to this same problem. I agree > >

Hi Warren, you can try to configure with the following export CFLAGS="-m64" export LDFLAGS="-L/usr/lib64" LLVM: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only make LLVM-GCC: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++

Greetings Sandeep I have tested crosscompiling llvm2.6 svn trunk 69279 + your patch for armv7a hardware. I wanted to see if it would build and if any unexpected failing tests in the testsuite would start to work using your patch. It built fine and your attached tests in the patch runs fine for me :) Now something fun this Generic test now works that previously failed: $ llvm-as <

Hi, I have run into the following strange behavior and wanted to ask for some advice. For the C program below, function sum() gets inlined in foo() but the code generated looks very suboptimal (the code is an extract from a larger program). Below I show the 32-bit x86 assembly as produced by the demo page on the llvm home page ("Output A"). As you can see from the assembly, after

Dear guys, I am having problem to split edges correctly. Mostly because the new basic blocks are creating infinite loops. Could someone help me fixing the code below? It is creating assembly like this one below. Block LBB1_9 was inserted to break the critical edge between blocks LBB1_3 and LBB1_8. But it changes the semantics of the original program, because, before, LBB1_8 was falling

Hi, I have a question about LoopVectorize. I wrote a simple test case, a dot product loop and found that packed instructions are generated when input arrays are integer, but not when they are float or double. If I modify the float example in http://llvm.org/docs/Vectorizers.html by adding restrict to the input arrays packed instructions are generated. Although it should not be required I tried