search for: indexregs

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

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

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

Here's an example patch of how dbgs() will be used. Essentially I will replace uses of errs() with dbgs(). I believe this is the correct thing to do because: - With #define NDEBUG, dbgs() == errs() - With debugging and -debug-buffer-size=0 (the default), dbgs() just passes output to errs(). - When -debug-buffer-size>0, you want to buffer ALL output so that you don't get some

Welcome to all Questions from veteran programmer with no LLVM backend experience evaluating llvm for creating a Hitachi 6309 backend. This post is about finding out more about machine instruction operands. The documentation I have read so far includes: - the online manuals - Building an LLVM Backend. Fraser Cormack Pierre-André Saulais - The Design of a Custom 32-bit RISC CPU

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

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

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

Hi David, I'm catching up on email at the moment so I don't know if you've done this, but patches should go to llvm-commits for review if you wouldn't mind. Thanks! -eric On Thu Dec 12 2013 at 8:39:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 > It also fixes a test which was requiring

This shouldn't have parsed. movq (%gs), %r14 That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week. That's probably why it printed as %ebp. I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy

...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). >&g...

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

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > 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. >

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

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