[llvm-commits] [llvm] r159695 - in /llvm/trunk: lib/Target/X86/X86InstrInfo.cpp lib/Target/X86/X86InstrInfo.h lib/Target/X86/X86TargetMachine.cpp test/CodeGen/X86/early-ifcvt.ll

[Chris Lattner]

Ok.  Load store targets can still fold memops into copies though...

-Chris

On Jul 5, 2012, at 10:17 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Jul 5, 2012, at 9:50 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>>> +/// getCMovFromCond - Return a cmov(rr) opcode for the given condition and
>>> +/// register size in bytes.
>>> +static unsigned getCMovFromCond(X86::CondCode CC, unsigned RegBytes) {
>>> +  static const unsigned Opc[16][3] = {
>>> +    { X86::CMOVA16rr,  X86::CMOVA32rr,  X86::CMOVA64rr  },
>> 
>> How feasible would it be to autogenerate these tables from tablegen?
> 
> Tricky. Condition code handling has a lot of differences between targets, and often for good reasons. ARM, for example, puts condition codes in an immediate operand instead of the opcode. That eliminates the need for these tables.
> 
> There isn't a lot of common ground that TableGen could exploit.
> 
>>  These and the load folding tables should really be able to be mechanically produced, meaning that each target doesn't have to implement (and maintain) the same stuff.
> 
> Actually, X86 is the only target that needs load folding tables. Most other architectures are load/store.
> 
> It would still be nice to have these tables emitted by TableGen, though. Even with an X86-specific backend.
> 
> /jakob
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120706/f149804d/attachment.html>