[LLVMdev] Random question about the x86 backend (and backends in general I suppose)

Evan Cheng evan.cheng at apple.com
Tue Jan 7 10:40:12 PST 2014


On Dec 30, 2013, at 8:40 PM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Dec 30, 2013, at 4:17 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
>> ----- Original Message -----
>>> From: "Craig Topper" <craig.topper at gmail.com>
>>> To: "Chandler Carruth" <chandlerc at google.com>
>>> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>>> Sent: Monday, December 30, 2013 2:29:50 PM
>>> Subject: Re: [LLVMdev] Random question about the x86 backend (and backends	in general I suppose)
>>> 
>>> 
>>> 
>>> I can't speak directly to the questions themselves, but I'll ask a
>>> couple back. When you say that some instructions are missing
>>> mayLoad, do these instructions have patterns? Tablegen can infer
>>> mayLoad/mayStores/hasSideEffects from patterns so it doesn't always
>>> need to be listed explicitly in the td files.
>> 
>> Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInstrInfo.inc file directly. I find this much easier. In theory, we'd like to move away from the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td).
> 
> In MHO, we should try to avoid redundancy as much as possible.  The only reason to have these flags is when instructions don't have patterns.

I'm fairly certain that Jakob put in an error (warning?) when tablegen detects redundant flags.

Evan


>  We should extend the tblgen pattern lexicon to make it possible to write patterns in more cases.  I think it's embarrassing that we still can't write a pattern for a move instruction :-/
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list