similar to: [LLVMdev] Publication: Two LLVM-related papers

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

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

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

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 all, i'm working on a LLVM back-end right now and i think I found a bug in an optimization pass. When compiling the following code using llvm-gcc (the current 2.5 release) with -O2 int main(int argc, char** argv) { char* pStr = "I" + (argc > 100); printf("%d\n", strcmp(pStr, "I") == 0); } the strcmp

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

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"

I'm doing some chi-square tests, and I recall some arbitrary rule that says each band must have at least 5 events in order for the test to be meaningful. Is there some way to do the banding automagically in R ? For instance, in the following survdiff, I'm trying to see if ADL affects survival. But when ADL=3,5 and 6, the number observed is too little. Anyway for me to tell R how to group

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

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

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:

This has been bugging me for years but never got around to spending a lot of time on it until I now want/need to use it for work stuff. Problem is simple I get access denied when trying to create a file in a directory that is not owned by me or my primary group that doesn't have world writable permissions. Ive also had similar issues with NFS mounts where I can't move/create/delete files

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

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

On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: > 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

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 Carlos, I am interested in your port of a MIPS-VLIW architecture. I plan to use a similar one for which there is no LLVM backend yet. Have you some example of your code? Best, Julien. On 22/10/11 11:10 , Carlos Sánchez de La Lama wrote: > 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

On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > >> In many places there is code that looks like: >> >> MBBI = next(MBBI); >> >> In C++0X there is a std::next that is likely to be in scope when these >> calls are made. And due to ADL the above call becomes ambiguous: >>