search for: tcreturn

On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > On 08/26/2010 13:17, Dale Johannesen wrote: >>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug with the .ll file that causes this? >&gt...

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}...

...just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo wasn't lowered to something that >>> the jit can output before the jit was run. Is this on ToT? >> >> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... > > Odd. I thought TCReturn was being lowered. At any rate can you > file a bug with the .ll file that causes this? It should be getting lowered in emitEp...

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false)...

On Aug 27, 2010, at 10:49 AM, Dale Johannesen wrote: > > On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > >> On 08/26/2010 13:17, Dale Johannesen wrote: >>>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>>> >>>> Odd. I thought TCReturn was being lowered. At any rate can you file a bug with the .ll file that causes this? >>> >>> It sh...

On 08/26/2010 13:17, Dale Johannesen wrote: >>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be ge...

...> In this case, the problem is that CTR and CTR8 are allocatable > because CTRRC and CTRRC8 are allocatable. You can set 'isAllocatable > = 0' in those register classes. Thanks for explaining! [We should add this to the docs somewhere]. > > Unfortunately, that breaks your TCRETURNri instructions. Sorry! I'm guessing that I can rewrite TCRETURN to reference CTR/CTR8 directly. I'll have to try that. > > Singleton register classes are dangerous because it is so easy to > extend the live range of virtual registers without checking for > interference. If yo...

...get it to print out the instruction when it happens? (just change the line above the error message to print it out to errs()). > > It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? > Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... Yuri

...e instruction when it happens? (just change the line above the error message to print it out to errs()). >> >> It basically means that a pseudo wasn't lowered to something that the jit can output before the jit was run. Is this on ToT? >> > > Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... Odd. I thought TCReturn was being lowered. At any rate can you file a bug with the .ll file that causes this? -eric

...ich by their nature can't >> be in SSA form. Lang and I have been trying to come up with some >> rules, but we haven't found the right set yet. > [We should add this to the docs somewhere]. http://llvm.org/bugs/show_bug.cgi?id=13058 >> Unfortunately, that breaks your TCRETURNri instructions. Sorry! > > I'm guessing that I can rewrite TCRETURN to reference CTR/CTR8 > directly. I'll have to try that. That should be possible, yes. /jakob

...9;t be in SSA form. Lang and I have been trying to come up with > >> some rules, but we haven't found the right set yet. > > > [We should add this to the docs somewhere]. > > http://llvm.org/bugs/show_bug.cgi?id=13058 > > >> Unfortunately, that breaks your TCRETURNri instructions. Sorry! > > > > I'm guessing that I can rewrite TCRETURN to reference CTR/CTR8 > > directly. I'll have to try that. > > That should be possible, yes. As it turns out, I don't need to (the patterns in question are never actually used in the curre...

Thanks! I also found test/CodeGen/ARM/ghc-tcreturn-lowered.ll, which tests only for thumbv7-eabi, so, i tried a few more variations: [x] arm64-apple-ios [x] arm64-apple-ios7.0.0 [x] arm64-apple-darwin [x] armv7-apple [x] thumbv7-apple [x] thumbv7-apple-darwin [x] i386-apple-ios [x] i386-apple-darwin [f] thumbv7-apple-ios [f] thumbv7-apple-ios7.0....

On 08/27/2010 12:13, Dale Johannesen wrote: > I don't think I believe this; emitPrologue should not be generating a > TCRETURN at all, and line 1037 is generating a PROLOG_LABEL. Why do > you say it's a TCRETURN? Sorry, my bad. I have set breakpoints by MI addresses. But it turns out that these addresses were reused and the second MIs created at these particular addressed are of interest, not the first ones. R...

...>> - insn: %RBP<def> = MOV64rr %RSP >>> - insn: PROLOG_LABEL <MCSym=.Ltmp3> >>> - insn: %RDI<def> = MOV64ri64i32 60910096 >>> - insn: %RAX<def> = MOV64ri >>> <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> >>> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp- >>> def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> - insn: RET >>> * PEI::insertPrologEpilogCode: === << before emitEpilogue >>> >>> Function only has on BB. Is this wro...

...convention and call clobbered registers to the eventual CALL MachineInstr? > > The simplest way would probably be to add separate X86ISD opcodes for > each desired set of call-clobbered registers. The problem is the large number of call-like instructions. We would need copies of CALL*, TCRETURN*, and TAILJMP* for each calling convention. I was hoping we could avoid that, and even get rid of the WINCALL instructions. What if InstrEmitter::EmitMachineNode called a target hook to add call-clobbered registers when II.isCall()? We would need some way of communicating the calling convention to...

On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: > > > One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. > > Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node with the calling convention somehow? > > Dan, do you have any thoughts on

Hi *, in the process of improving the ios experience with ghc, I ran into the following issue: the produced llvm code[1] compiles for `armv7-apple-darwin`, unless optimization level is 0, however it fails to compile at all for `armv7-apple-ios`. I was able to reduce the produced code, while retaining the compilation issue on `armv7-apple-ios` to the following sample case: —————————————————————

...optimizations like dead code elimination. (You don't want to DCE a stack pointer update). In this case, the problem is that CTR and CTR8 are allocatable because CTRRC and CTRRC8 are allocatable. You can set 'isAllocatable = 0' in those register classes. Unfortunately, that breaks your TCRETURNri instructions. Sorry! Singleton register classes are dangerous because it is so easy to extend the live range of virtual registers without checking for interference. If you accidentally cross two live ranges, you get horrible spilling as you've seen. We try to use explicit unallocatable physr...

On Thu, 7 Jun 2012 22:14:00 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > > > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > > Predecessors according to CFG: BB#0 BB#1 > > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, > >

On 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is generated. Normally that's >>>...