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

[Hal Finkel]

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