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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131230/f71a36fb/attachment.html>

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131230/b8fdfb54/attachment.html>

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