search for: delayslotfiller

.... > So I guess the question I have is, are MBBs like BB#7 above legal, Funny question :). When I was working on the sparc backend, it was unclear how best to represent delay slots. The approach I took was to pretend that they didn't exist for most of the compiler backend, then have DelaySlotFiller create them right before the asmprinter ran. The idea was to eventually extend DelaySlotFiller to put something better than a nop in them :) This all works as long as the asmprinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough violates. As f...

...gt; So I guess the question I have is, are MBBs like BB#7 above legal, > > Funny question :). When I was working on the sparc backend, it was unclear how best to represent delay slots. The approach I took was to pretend that they didn't exist for most of the compiler backend, then have DelaySlotFiller create them right before the asmprinter ran. The idea was to eventually extend DelaySlotFiller to put something better than a nop in them :) > > This all works as long as the asmprinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough violates. &...

On 11/12/2009, at 10:43 AM, Anton Korobeynikov wrote: > Hi, Chris > >> That is target independent code, so you should not put sparc specific changes there. It sounds like one of the sparc-specific target hooks is wrong. > Since sparc does not provide any hooks for operation of branches (e.g. > AnalyzeBranch and friends) it might be possible that generic codegen > code is

...question I have is, are MBBs like BB#7 above legal, >>> >> Funny question :). When I was working on the sparc backend, it was unclear how best to represent delay slots. The approach I took was to pretend that they didn't exist for most of the compiler backend, then have DelaySlotFiller create them right before the asmprinter ran. The idea was to eventually extend DelaySlotFiller to put something better than a nop in them :) >> >> This all works as long as the asmprinter is a simple pass through that doesn't look at the code, which isOnlyReachableByFallthrough viol...

Hi, Chris > That is target independent code, so you should not put sparc specific changes there.  It sounds like one of the sparc-specific target hooks is wrong. Since sparc does not provide any hooks for operation of branches (e.g. AnalyzeBranch and friends) it might be possible that generic codegen code is broken in absence of these hooks. -- With best regards, Anton Korobeynikov Faculty

hi guys I need to get llvm to support vliw architecture. Can you please point me in the right direction. we have managed to get it to compile into simple assemble and now need it to be able to schedule the instructions in parrallel. any help would be appreciated Regards Junior

On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote: > Hi list, > > in our LLVM-based-project we are writing a backend for our > processor. The > architecture is a quite straight-forward RISC, but it does not have > hardware interlocks, i.e. data hazards involving memory access must be > resolved by the compiler, either by scheduling unrelated > instructions or >

...han I ever wanted ;-), I arrived at configuring llvm-2.2 like this: CFLAGS=-m32 CXXFLAGS=-m32 ./configure --prefix=$HOME The assembler errors are finally gone (phew!, and thanks for all the help!), but I get linker errors now: llvm[3]: Linking Release Object Library LLVMX86.o llvm[3]: Compiling DelaySlotFiller.cpp for Release build /usr/bin/ld: Relocatable linking with relocations from format elf64-x86-64 (/home/jo/Delta/llvm-2.2/lib/Target/X86/Release/X86ATTAsmPrinter.o) to format elf32-i386 (/home/jo/Delta/llvm-2.2/Release/lib/LLVMX86.o) is not supported make[3]: *** [/home/jo/Delta/llvm-2.2/Release/l...

...add reg1025, 2 add reg1026, 3 add reg1027, 4 after register allocation: load 0x1234, reg1 load 0x1236, reg2 load 0x1238, reg3 add reg1, 1 add reg2, 2 add reg3, 3 store reg1, 0x1234 load 0x1240, reg1 add reg1, 4 Which won't work on our platform. It is missing 2 NOOPs after the last load. The DelaySlotFiller could add the two NOOPs, but that would be less optimal than doing the store-load before the add of reg2 and reg3 (no NOOP in that case). >> And more generally: Is the hazardRecognizer the right and only way to >> solve our NOOP-minimizing problem? > > Perhaps you want to do th...

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

Hi, in section B.29. (Write State Register Instructions) of 'The SPARC Architecture Manual Version 8' it is said that the "The write state register instructions are delayed-write instructions." The Y-register is a state-register. Furthermore in the B.29-secion there is a programming note saying: MULScc, RDY, SDIV, SDIVcc, UDIV, and UDIVcc implicitly read the Y register.