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

[Hal Finkel]

----- Original Message -----
> From: "Owen Anderson" <resistor at mac.com>
> To: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, January 7, 2014 1:09:05 PM
> Subject: Re: [LLVMdev] Random question about the x86 backend (and	backends	in general I suppose)
> 
> 
> 
> 
> 
> On Jan 7, 2014, at 10:47 AM, Jakob Stoklund Olesen < stoklund at 2pi.dk
> > wrote:
> 
> 
> 
> 
> On Jan 7, 2014, at 10:40 AM, Evan Cheng < evan.cheng at apple.com >
> wrote:
> 
> 
> 
> 
> 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.
> 
> Tablegen will emit an error if the specified flags are inconsistent
> with the patterns.
> 
> If you clear the guessInstructionProperties flag, it will also refuse
> to infer flags from patterns, while still verifying the manually
> specified flags against the patterns when possible.
> 
> 
> I’d like to throw out that having the inference present can be a
> massive problem at time. It’s reasonably common to have a multi
> class that is reused for a number of different instructions, say
> different types of load. Some of the instantiations of the class
> have a pattern (say a normal i32 load) and some don’t (load of an
> illegal type, for example). In this case, you need to set the isLoad
> flag on the defs in the multiclass in order the make sure the latter
> get it properly, but you’ll get warnings (errors?) from tblgen about
> redundant flags on the former. The typical workaround is to
> duplicate the multiclass for with-flags and without-flags, which is
> even more useless duplication than having the flags ever was.

I'd like to second this. The problem with the current inference scheme is that it is not consistent: instructions sometimes get inferred flags, depending on how their patterns are specified, and sometimes don't. Furthermore, auditing those inferred flags is not easy, and because this is a correctness issue, they do need to be checked.

My preference would be for TableGen to warn if a flag that is implied by a pattern is missing from the instruction, and nothing more than that.

 -Hal

> 
> 
> —Owen
> 
> 
> _______________________________________________
> 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