Displaying 2 results from an estimated 2 matches for "nonamedpositionallyencodedoperands".
2014 Mar 13
5
[LLVMdev] Be Careful with Positionally-Encoded Operands (AArch64, Mips, AMDGPU, etc.)
...x operands that PPC uses for handling memory operands), and PowerPC needs the behavior that named and positional operands are disjoint so that we can start transitioning toward using named mapping, so I've added a new TableGen target bit to disable this problematic overlapping operand behavior (noNamedPositionallyEncodedOperands) in r203767.
This means that in lib/Target/PowerPC/PPC.td, we have:
def PPCInstrInfo : InstrInfo {
...
let noNamedPositionallyEncodedOperands = 1;
...
}
I'd like those maintaining the current backends (especially AArch64, Mips, AMDGPU, which I know to be problematic in this regard) to tr...
2014 Mar 13
2
[LLVMdev] Be Careful with Positionally-Encoded Operands (AArch64, Mips, AMDGPU, etc.)
...nds), and
> > PowerPC needs the behavior that named and positional operands are
> > disjoint so that we can start transitioning toward using named
> > mapping, so I've added a new TableGen target bit to disable this
> > problematic overlapping operand behavior
> > (noNamedPositionallyEncodedOperands) in r203767.
> >
> > This means that in lib/Target/PowerPC/PPC.td, we have:
> >
> > def PPCInstrInfo : InstrInfo {
> > ...
> >
> > let noNamedPositionallyEncodedOperands = 1;
> >
> > ...
> > }
> >
> > I'd like those...