similar to: [LLVMdev] Bug in optimization pass related to strcmp and big endian back-ends

On Tue, Aug 11, 2009 at 1:13 AM, Stripf, Timo<Timo.Stripf at itiv.uni-karlsruhe.de> wrote: > On little endian machines the code works correct but on big endian %lhsv > must be compared against 73 << 8. If llvm-gcc thinks it's compiling for a little-endian target, the optimizers will assume the target is little-endian... what are you trying to do? -Eli

I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. -Timo -----Ursprüngliche Nachricht----- Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Hi, i've two papers that could be listed on the LLVM publication page. http://www.llvm.org/pubs/ The first paper describes an architecture description language and LLVM back-end generation out of an ADL. The second paper describes a cluster VLIW back-end for LLVM 2.9, just before this VLIW initiative started for LLVM. Kind regards, Timo Stripf Stripf, T.; Koenig, R.; Becker, J.; , "A

Stripf, Timo wrote: > I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. > > I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. > > -Timo LLVM IR is very target dependent. The IR knows about things

Hi all, i'm writing an back-end for a new research processor architecture and have problems with the DAG Combiner. The processor architecture supports i1 and i32 registers. 1-bit registers are mainly used as comparison result but basic operations like OR are not possible between i1 registers. So I wrote custom lowering for i1 OR operations and replaced it by (trunc (or (aext x), (aext

Stripf, Timo wrote: > I thought the LLVM IR is target independent Yes. and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. No. > I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. LLVM IR contains a target-information line but is otherwise target

Alright thank you all for your help and information and sry for describing it as a bug. For a "fast" workaround I simple use llvm-gcc with -O0, modify the endian information within the ll file and use opt to optimize the code. That way also the debugging information is not removed and everything works atm fine for a non-trivial application. Later I'll also modify the front-end to

Evan, What would change if tomorrow we got a VLIW target/back end with some certain properties - let's say no intra-packed deps - would it sway your opinion in either direction? Would it be a natural prerogative to implement it certain way for such hypothetical contributor/submitter? Thanks. Sergei Larin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

Hi Jakob, I forget to mention that I'm working atm on the old 2.5 release code base and not on the svn. So I don't know if the problem still exists. I'm going to test it now. > The Blackfin DSP can do simple i1 operations with the CC flag and > status bits. Initially I also marked i1 as a legal type, but it caused > a lot of problems. Now I pretend that the CC register

On Oct 25, 2011, at 1:59 AM, Stripf, Timo wrote: > Hi all, > >> Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? > > I attached the packing and unpacking pass I used within my backend. In my solution multiple

Hi all, > Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? I attached the packing and unpacking pass I used within my backend. In my solution multiple MachineInstruction are packed into one variadic "PACK"

On 24/08/2009, at 01.19, Stripf, Timo wrote: > > I had also a lot of problems to get the i1 operations working. E.g. > I had to override the getSetCCResultType to get is working and for > ADDE/ADDC the i1 target registers are hardcoded. What is your SetCCResultType now? Can you compile the CodeGen/Blackfin/basic-i1.ll test case? I never got that one working with legal i1. The

Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible:

Carlos, Absolutely. And an addition to live range detection needs to be made aware of the global cycle... and it needs to be done regardless of representation methodology. Same for any pass that would care for packets. The important observation here IMHO is that "packetization" at early stage (before RA) is tentative, and RA can change the landscape, which must be somewhat finalized

I converted now my back-end with legal i1 lowering to the 2.6 branch and my original problem with the DAG combiner didn't occur any more and seems to be fixed. setOperationAction(ISD::OR, MVT::i1, Promote) also works fine for logical operations. > What is your SetCCResultType now? I changed SetCCResultType to return MVT::i1 type. > Can you compile the CodeGen/Blackfin/basic-i1.ll

Hi Sergei, > What would you say to a some sort of a "global cycle" field/marker to > determine all instructions scheduled at a certain "global" cycle. That way > the "bundle"/packet/multiop can be identified at any time via a common > "global cycle" value. But RA would need to know about this global cycle field, right? Cause a register can be

Evan, Timo, Carlos (and everyone else), I have somewhat similar interest. What would you say to a some sort of a "global cycle" field/marker to determine all instructions scheduled at a certain "global" cycle. That way the "bundle"/packet/multiop can be identified at any time via a common "global cycle" value. I could see that being set first in pre-ra

It seems to me that the concept of insn bundles or packets is needed with different characteristics, depending where it's used. At early scheduling, when there may be no MachineInstruction objects yet, the data structure or annotation that's needed may be quite different from that needed at or near code generation and emission. I think that what Sergei is talking about fits well with

Hi Timo, your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from MachineInstruction so I call it "MachineInstructionBundle") and pack/unpack so RegAlloc works on the bundles… I really think this is the way to incorporate VLIW support to LLVM. I guess a need for some of this to make to LLVM trunk is to have a backend

Quoting Chris Lattner <clattner at apple.com>: Dear staff, I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 statically (compile all libraries statically to the executable) and got the bc file, named it as mysqld.bc3. I use the command to pass: opt -load <poolalloc install dir>/lib/libLLVMDataStructure.so -ds-aa mysqld.bc3 -print-alias-sets -disable-output