similar to: [LLVMdev] Noob Backend Orientation

Hello everybody, we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops when compiling to bytecode without any optimizations. Apparently what happens is that the loop header is duplicated, which results in two entry points for the loop. Since this could obstruct subsequent loop optimizations, it might be interesting to further investigate this behavior. To show the problem, I have

On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: > we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops > when compiling to bytecode without any optimizations. Apparently what > happens is that the loop header is duplicated, which results in two > entry points for the loop. this is actually a problem with the tailduplication pass of llvm. it does not consider

On Jun 11, 2008, at 6:27 AM, Florian Brandner wrote: > On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: >> we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops >> when compiling to bytecode without any optimizations. Apparently what >> happens is that the loop header is duplicated, which results in two >> entry points for the loop. > > this is

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

Reid Spencer wrote: > Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc no, did'nt change it. the typo before seems to be an error while copying from the terminal. i've cleaned everything and tried again. this is the messsage: [brandner:/localtmp/brandner/dev/llvm-test:529] make -j1 TEST=nightly 2>&1 | tee report.nightly.raw.out

On Fri, 04 May 2007 14:37:53 +0200 Florian Brandner <fbrandne at mail.tuwien.ac.at> wrote: >hello, > >i've problems running the llvm-test suite using debian linux and make >3.81. it works fine on my laptop, running openSuse and make 3.81. > >i already tried to install make 3.75 and 3.79, both did not work. > >the error message is: > >make[1]: *** No rule to

hello, i've problems running the llvm-test suite using debian linux and make 3.81. it works fine on my laptop, running openSuse and make 3.81. i already tried to install make 3.75 and 3.79, both did not work. the error message is: make[1]: *** No rule to make target `Output/sse.expantfft.bc', needed by `Output/sse.expandfft.linked.rbc'. Stop. using make -p, i see that

It seems that tail duplication can make a reducible CFG irreducible (example below). Is that intentional? Are there other optimizations that have that property? Is irreducibility a problem for existing LLVM passes? It looks like there was once an open project for a pass to make irreducible graphs reducible. Was that ever implemented? - Mark ; "opt -inline -tailduplicate" makes an

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

For the following code: struct XBeePacket; typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); struct XBeePacket { bool mField1; CompletionProc mCompletionProc; }; Why does clang emit this IR? %struct.XBeePacket = type { i8, {}* } define void @MyCompletionProc(%struct.XBeePacket* %inPacket, i8*

Hi Quentin, > On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at apple.com> wrote: > 1. If anyone else is interested for such concept? yes, we are! (https://github.com/t-crest) > 2. What kind of information should we make accessible in an hypothetical MachineModule? I.e., how do you plan to use the MachineModulePass so that we make the right design decisions for the

Duncan Sands wrote: >> My initial reaction is that if one were to decorate MachineInstr's >> with the LLVM level pointer values that they use for reading >> and writing memory, > > this is already the case: SrcValue and SVOffset. Ah, that's right. I went back and read the discussion from January, and Florian Brandner explains there that the real culprit is the

Hi Rick, this is a bug in Clang's LLVM-IR code generator: http://llvm.org/bugs/show_bug.cgi?id=14920 Best, Florian On Sunday, January 20, 2013 01:57:37 Rick Mann wrote: > For the following code: > > struct XBeePacket; > > typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); > > struct > XBeePacket > { >

On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > On Fri, 4 May 2007, Florian Brandner wrote: > > i had a look at the SelectionDAG based schedulers. it seems that > > aliasing loads/stores are chained together by the DAGCombiner. after > > scheduling, when the MachineInstrs are created, the alias information > > cannot be used anymore in the current

On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote: > I have a patch against llvm 2.4 that fixes this issue, but did not have > the time to post the patch here. I'll do so by tomorrow. here is the patch, still against llvm 2.4. I had a short look on trunk, but it seems that there are several conflicts. Maybe a tablgen expert should have a look at this - I also do not know if

hi, i found a problem in LLVM regarding the matching of 'Constant' nodes in the instruction selector. the testcase is for x86, but similar testcases for the other architectures (e.g. ppc) should be easy to create. i'm using the llvm-gcc 2.0 prerelease binary package. here is the testcase: int foo(int bar) { asm("movl %1, %0" : "=r"(bar) : "i"(5));

On Fri, Jun 15, 2007 at 04:16:57PM +0200, Florian Brandner wrote: > hi, > > > Florian Brandner wrote: > > Dan Gohman wrote: > >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > >>> Right. The original Value*'s are preserved in the DAG, but dropped when > >>> MachineInstrs are created. We could add a machineoperand to

Hi all, I am trying to build a global control flow graph at machine code level. Essentially, I need the handles to the MachineFunction's corresponding to every call site inside a MachineFunction in order to get the handles to MachineBasicBlock's with return statements inside the callee. Currently, the codegen module processes one MachineFunction at a time and hence I can't find a way

hi, i`m working on a machine instruction scheduler for an VLIW architecture. loads are somewhat expensive on this architecture, thus i would like to reorder unrelated loads/stores to better hide load latencies. to do this, i would need alias information on machine instructions, i.e., which machine instructions may access the same memory region. as far as i know, this is not available at the

On Thursday 03 April 2008 22:00:34 Dan Gohman wrote: > However, for people just interested in post-regalloc scheduling and > VLIW packing and similar things, MemOperands aren't the only approach. > A potentially better way to do this would be to extend MachineInstrs > to preserve the chain dependencies from the SelectionDAG. the selection dag may already contain unnecessary