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

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

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.

Thanks,
/jakob

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.

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140107/75de8f22/attachment.html>

On Jan 7, 2014, at 10:47 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
wrote:
> 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.
Sorry, that wasn’t accurate.

With guessInstructionProperties=0, Tablegen will refuse to invent flags out of
thin air for instructions that have neither patterns nor explicit flags. It will
still infer flags for instructions with patterns and no explicit flags.

It will always complain when flags inferred from patterns are inconsistent with
explicit flags.

Thanks,
/jakob