llvm dev - Aug 2017 - RFC/bikeshedding: Separation of instruction and pattern definitions in LLVM backends

On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com>
wrote:
> One thing to be aware of with this is that (IIRC) tablegen uses the pattern
to infer things about the pattern. One example I vaguely remember is that an
empty pattern would result in the same effect as hasSideEffects=1 and I think
there were others.
Thanks for the note - excellent point. Looking at
CodeGenDAGPatterns.cpp, it seems in the absence of a pattern
hasSideEffects will be 1, while mayLoad and mayStore default to 0.
Back in 2012, Jakob Stoklund Olesen added the
guessInstructionProperties flag, which causes an error
<https://reviews.llvm.org/rL162460> if a property isn't set explicitly
and can't be inferred. It doesn't look like any other in-tree targets
have ended up enabling this, but it looks like it would be worth
enabling for RISCV, particularly if going ahead with splitting
instructions and patterns.

Best,

Alex

If no pattern is provided, does the implied 'hasSideEffects' take
preference over an explicit 'let hasSideEffects = 0'?

I assume not, but I'd like to be certain.

Knowing about this default for a NULL pattern is important though, I was
certainly unaware of this until this discussion and will have to revisit my
existing definitions which have NULL patterns in case 'hasSideEffects'
doesn't have the value I would expect for the instruction.

Thanks,

    MartinO

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex
Bradbury via llvm-dev
Sent: Monday, August 21, 2017 3:32 PM
To: Daniel Sanders <daniel_l_sanders at apple.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; John Leidel <john.leidel at
gmail.com>
Subject: Re: [llvm-dev] RFC/bikeshedding: Separation of instruction and pattern
definitions in LLVM backends

On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com>
wrote:
> One thing to be aware of with this is that (IIRC) tablegen uses the pattern
to infer things about the pattern. One example I vaguely remember is that an
empty pattern would result in the same effect as hasSideEffects=1 and I think
there were others.
Thanks for the note - excellent point. Looking at CodeGenDAGPatterns.cpp, it
seems in the absence of a pattern hasSideEffects will be 1, while mayLoad and
mayStore default to 0.
Back in 2012, Jakob Stoklund Olesen added the guessInstructionProperties flag,
which causes an error <https://reviews.llvm.org/rL162460> if a property
isn't set explicitly and can't be inferred. It doesn't look like any
other in-tree targets have ended up enabling this, but it looks like it would be
worth enabling for RISCV, particularly if going ahead with splitting
instructions and patterns.

Best,

Alex
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

On 22 August 2017 at 10:41, ORiordan, Martin <martin.oriordan at
intel.com> wrote:
> If no pattern is provided, does the implied 'hasSideEffects' take
preference over an explicit 'let hasSideEffects = 0'?
>
> I assume not, but I'd like to be certain.
>
> Knowing about this default for a NULL pattern is important though, I was
certainly unaware of this until this discussion and will have to revisit my
existing definitions which have NULL patterns in case 'hasSideEffects'
doesn't have the value I would expect for the instruction.
The explicit let hasSideEffects=0 takes preference. You can audit this
by looking at build/lib/Target/Mytgt/MytgtGenInstrInfo.inc. Look in
`extern const MCInstrDesc MytgtInsts[]`
You'll see `MCID::UnmodeledSideEffects` for any instruction where
hasSideEffects ended up being true (either explicitly specified or
inferred).

Best,

Alex

On 21 August 2017 at 15:32, Alex Bradbury <asb at asbradbury.org>
wrote:
> On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at
apple.com> wrote:
>> One thing to be aware of with this is that (IIRC) tablegen uses the
pattern to infer things about the pattern. One example I vaguely remember is
that an empty pattern would result in the same effect as hasSideEffects=1 and I
think there were others.
>
> Thanks for the note - excellent point. Looking at
> CodeGenDAGPatterns.cpp, it seems in the absence of a pattern
> hasSideEffects will be 1, while mayLoad and mayStore default to 0.
> Back in 2012, Jakob Stoklund Olesen added the
> guessInstructionProperties flag, which causes an error
> <https://reviews.llvm.org/rL162460> if a property isn't set
explicitly
> and can't be inferred. It doesn't look like any other in-tree
targets
> have ended up enabling this, but it looks like it would be worth
> enabling for RISCV, particularly if going ahead with splitting
> instructions and patterns.
To updated on this, I've found guessInstructionProperties requires the
standard TargetOpcode::* instructions to have their properties
explicitly set. https://reviews.llvm.org/D37065 does this. If anyone
has any insight in to why TargetOpcode::PHI must have hasSideEffects
set, that would be interesting.

Best,

Alex