search for: indexreg

I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 right near the end of compiling llvm-gcc in valarray-inst.cc. assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow scaling by ESP" Does this build on Linux ? My remote Linux box has died and not a ble to reset it for a day or two. /home/ang/build/llvm-gcc/./gcc/xgcc -shared-libgcc -B/home/ang/build/llvm-gcc/./ gcc -nostdinc++ -L/home/ang/build/...

...uld get something like this: mov @a, %b1 // moving this immediate to a base register, which is what we want In 3.6, we now get this: mov @a, %r0 // r0 = gpr mov %r0, %b1 // b1 = base reg The register class looks like this: def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>; I have absolutely no idea why this is not matching any longer? The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination). This must be an issue with something else and not the tablegen but if that was the case I'm not...

This looks like pr4572. Evan On Jul 27, 2009, at 3:25 AM, Aaron Gray wrote: > I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 > right near the end of compiling llvm-gcc in valarray-inst.cc. > > assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow > scaling by ESP" > > Does this build on Linux ? > > My remote Linux box has died and not a ble to reset it for a day or > two. > > /home/ang/build/llvm-gcc/./gcc/xgcc -shared-libgcc -B/home/ang/build/ &gt...

...t; << Base.FrameIndex << '\n' + dbgs() << "nul"; + dbgs() << " Base.FrameIndex " << Base.FrameIndex << '\n' << " Scale" << Scale << '\n' << "IndexReg "; if (IndexReg.getNode() != 0) IndexReg.getNode()->dump(); else - errs() << "nul"; - errs() << " Disp " << Disp << '\n' + dbgs() << "nul"; + dbgs() << " Disp &quo...

.../Motorola 6309/6809 which too provides dedicated indexing (addressing) registers. In fact in all binary operations the second operand is either immediate or some kind of a memory reference via a index/address register. The syntax being: {[}{OffsetReg | Disp{5,8,16}},{- | --}IndexReg{+ | ++ | ]} OffsetReg can be 8bit or 16bit accumulator (so only certain regs allowed) Displacment can be 5, 8 or 16 bit signed IndexReg can only be special index registers or PC or stack + ++ is post increment by 1, 2 repsectively - -- is pre decrement by 1, 2 respectively [ ] the entire e...

...h is what > we want > > > > In 3.6, we now get this: > > > > mov @a, %r0 // r0 = gpr > > mov %r0, %b1 // b1 = base reg > > > > The register class looks like this: > > > > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, > BaseRegs)>; > > > > I have absolutely no idea why this is not matching any longer? > > > > The fix here is to define an MI with explicit single register class (ie > it only allows PTRRegs as the destination). > > > > This must be an issue with someth...

...if (BaseReg) { + // See Table 2-1 "16-Bit Addressing Forms with the ModR/M byte" + static const int R16Table[] = { 0, 0, 0, 7, 0, 6, 4, 5 }; + unsigned RMfield = R16Table[BaseRegNo]; + + assert(RMfield && "invalid 16-bit base register"); + + if (IndexReg.getReg()) { + unsigned IndexReg16 = R16Table[GetX86RegNum(IndexReg)]; + + // Must have one of SI,DI (4,5), and one of BP/BX (6,7) + assert(((IndexReg16 ^ RMfield) & 2) && + "invalid 16-bit base/index register combination"); + assert(Sc...

...moving this immediate to a base register, which is what we want > > In 3.6, we now get this: > > mov @a, %r0 // r0 = gpr > mov %r0, %b1 // b1 = base reg > > The register class looks like this: > > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>; > > I have absolutely no idea why this is not matching any longer? > > The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination). > > This must be an issue with something else and not the tablegen but if...

...Table 2-1 "16-Bit Addressing Forms with the ModR/M byte" > + static const int R16Table[] = { 0, 0, 0, 7, 0, 6, 4, 5 }; > + unsigned RMfield = R16Table[BaseRegNo]; > + > + assert(RMfield && "invalid 16-bit base register"); > + > + if (IndexReg.getReg()) { > + unsigned IndexReg16 = R16Table[GetX86RegNum(IndexReg)]; > + > + // Must have one of SI,DI (4,5), and one of BP/BX (6,7) > + assert(((IndexReg16 ^ RMfield) & 2) && > + "invalid 16-bit base/index register combination&q...

...> BuildMI(MBB,MBB.end(),DL,TII->get(X86::MOV64rm),X86::R14) > .addReg(X86::GS); > /* 2 mov %r15, %gs:0x0(%r14) */ > MachineOperand baseReg = MachineOperand::CreateReg(X86::GS,false); > MachineOperand scaleAmt = MachineOperand::CreateImm(0x1); > MachineOperand indexReg = MachineOperand::CreateReg(X86::R14,false); > MachineOperand disp = MachineOperand::CreateImm(0x0); > > BuildMI(MBB, MBB.end(), DL, TII->get(X86::MOV64mr)) > .add(baseReg) > .add(scaleAmt) > .add(indexReg); > > /* both instructions give the foll...

...w get this: >>> > >>> > mov @a, %r0 // r0 = gpr >>> > mov %r0, %b1 // b1 = base reg >>> > >>> > The register class looks like this: >>> > >>> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, >>> BaseRegs)>; >>> > >>> > I have absolutely no idea why this is not matching any longer? >>> > >>> > The fix here is to define an MI with explicit single register class >>> (ie it only allows PTRRegs as the destination). >&...

The size suffix thing is a weird quirk in our assembler I should look into fixing. Instructions in at&t syntax usually have a size suffix that is often optional For example: add %ax, %bx and addw %ax, %bx Are equivalent because the register name indicates the size. but for an instruction like this addw $1, (%ax) There is nothing to infer the size from so an explicit suffix is

...> >>>> > mov @a, %r0 // r0 = gpr >>>> > mov %r0, %b1 // b1 = base reg >>>> > >>>> > The register class looks like this: >>>> > >>>> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, >>>> BaseRegs)>; >>>> > >>>> > I have absolutely no idea why this is not matching any longer? >>>> > >>>> > The fix here is to define an MI with explicit single register class >>>> (ie it only allows PTRRegs as...

Hi, I've been trying to teach LLVM that pointers are 128-bit long, which segfaults with some seemingly unrelated stacktrace when I try to take an address of a variable. Since stack saving and loading seems to work fine, I dare to assume the instruction causing problems there is leaq. Now I've done a search for leaq of the entire LLVM codebase with no success and I'd like to know which

...t; > mov @a, %r0 // r0 = gpr >>>>> > mov %r0, %b1 // b1 = base reg >>>>> > >>>>> > The register class looks like this: >>>>> > >>>>> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, >>>>> BaseRegs)>; >>>>> > >>>>> > I have absolutely no idea why this is not matching any longer? >>>>> > >>>>> > The fix here is to define an MI with explicit single register class >>>>> (ie i...

...bleIndex()) { > + if (Is64BitMode || IsPIC) { > + DispForReloc = &Op3; > + } else { > + DispVal = 1; > + } > + } else { > + DispVal = 1; > + } > + > + const MachineOperand &Base = MI.getOperand(Op); > + const MachineOperand &IndexReg = MI.getOperand(Op+2); > + > + unsigned BaseReg = Base.getReg(); > + > + // Is a SIB byte needed? > + if (IndexReg.getReg() == 0 && > + (BaseReg == 0 || X86RegisterInfo::getX86RegNum(BaseReg) != > N86::ESP)) { > + if (BaseReg == 0) { // Just a displacem...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...> >>>> > mov @a, %r0 // r0 = gpr >>>> > mov %r0, %b1 // b1 = base reg >>>> > >>>> > The register class looks like this: >>>> > >>>> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>; >>>> > >>>> > I have absolutely no idea why this is not matching any longer? >>>> > >>>> > The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination). >>>&gt...

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

...t; > mov @a, %r0 // r0 = gpr >>>>> > mov %r0, %b1 // b1 = base reg >>>>> > >>>>> > The register class looks like this: >>>>> > >>>>> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>; >>>>> > >>>>> > I have absolutely no idea why this is not matching any longer? >>>>> > >>>>> > The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination)....