llvm dev - Jan 2014 - [LLVMdev] Random question about the x86 backend (and backends in general I suppose)

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

 -Hal
> 
> 
> Instructions without patterns are marked hasSideEffects=1 which is
> more restrictive than mayLoad/mayStore.
> 
> 
> 
> On Mon, Dec 30, 2013 at 1:56 PM, Chandler Carruth <
> chandlerc at google.com > wrote:
> 
> 
> 
> Having worked with a few people to better understand the tablegen
> descriptions of instructions and patterns in LLVM's backend and
> looking at x86's pretty heavily, I have some questions:
> 
> 
> 1) Are there instruction definition flags that are really just "when
> needed"? I'm thinking of things like "mayLoad" which is
really
> alarmingly missing from a bunch of instructions in x86 which load.
> Is this OK? Is this a bug, or just suboptimal?
> 
> 
> 2) Are all of the flags in Target.td (lines 356 - 381) the
> "recommended" set? Are any of them no longer really important to
> mark?
> 
> 
> 3) It would be really nice to keep track of the flags for
> instructions which are added (or removed) from the "recommend
set",
> and whether or not backends have had their instruction definitions
> audited to be up-to-date here. Essentially, I wonder if it would be
> useful to keep PRs open with a nice list of low-hanging maintenance
> tasks on the instruction definition tables for people interested.
> 
> 
> 4) If I'm reading the td files and I see things that are obviously
> wrong (for example, an instruction which loads but is not marked as
> such, or instructions which should be marked as (potentially)
> trivially rematerializable), should I just fix them and submit those
> fixes? Can I even write test cases for most of these? Clearly, what
> I consider "obviously wrong" will be informed by answers to #1
and
> #2 above.
> 
> 
> 
> --
> ~Craig
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

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

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