similar to: [LLVMdev] instruction selector failure

On Wed, 16 May 2007, Florian Brandner wrote: > 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)

Chris Lattner wrote: > On Wed, 16 May 2007, Florian Brandner wrote: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049609.html > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049608.html > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049606.html > >

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

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

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 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

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 > { >

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

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

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

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 recently switched to LLVM-GCC 4.2 on OS X, to go around a bug caused by gcc with optimized code. Unfortunately, I ran into another weird problem on LLVM-GCC. In my code, there's a file with a bunch of inline assembly blocks, that worked fine with GCC 4.2. Now, when compiling with LLVM-GCC 4.2, weird things happen. Here's an example: (the blocks are larger than that, but a single

You may find it helpful to reference http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html. In particular, the information regarding clobbers and constraints. Generally speaking, it's best not to use inline assembly at all. What are you trying to do that you find it necessary? On Mar 16, 2010, at 12:30 AM, Fred / Kettch wrote: > Hi, > > I recently switched to LLVM-GCC

On Jul 31, 2009, at 10:24 AM, Michael Graumann wrote: > Hi, > I’ am trying to insert an InlineAsm Instruction in my pass, which > FunctionType do I need for Inlineasm? > If I understand it right, I need a call instruction to insert the > new produced InlineAsm? > > Thanks for help Inline asm works like a "callee". So for: call void asm sideeffect

Hi, I' am trying to insert an InlineAsm Instruction in my pass, which FunctionType do I need for Inlineasm? If I understand it right, I need a call instruction to insert the new produced InlineAsm? Thanks for help, Michael for (BasicBlock::iterator bi = i->begin(), be = i->end(); bi != be; ++bi){ std::vector<const Type*> asm_arguments;

Thank you Chris, for your hint, but I am still too stupid. I tried two versions asm_arguments.push_back(Type::VoidTy); FunctionType *asm_type = FunctionType::get(Type::VoidTy, asm_arguments, false); Alternatively FunctionType *asm_type = FunctionType::get(Type::VoidTy, std::vector<const Type*>(), false); . Can you give me a snippet of example code, or somebody else?

Hi all, I'm trying to figure out which parameters of a given InlineAsm instruction are its inputs, and which are the outputs (rationale: make sure MSan doesn't check the output parameters of an asm() statement). As far as I understand, this information is only available through the ConstraintInfoVector for the InlineAsm. However there's no exact match between the constraints and the

On Fri, 4 May 2007, Florian Brandner wrote: > Chris Lattner wrote: >> There are a couple of ways to do this. Is your scheduler a prepass >> scheduler (before regalloc) or a post-pass scheduler (after regalloc)? > > it is a post-pass scheduler, which operates on MachineInstrs. we need to > run it after register allocation to hide latencies of spill code, > prolog, and