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

ORiordan, Martin via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 22 03:32:08 PDT 2017


Thanks Alex,

Yes, that is what I expected the behaviour would be.  So for the pattern-less definitions, it should be sufficient to wrap them in a 'let hasSideEffects = 0 in { ... }' unless of course the instruction really does have side-effects.  Safer to be explicit anyway.

All the best,

	MartinO

-----Original Message-----
From: Alex Bradbury [mailto:asb at asbradbury.org] 
Sent: Tuesday, August 22, 2017 10:59 AM
To: ORiordan, Martin <martin.oriordan at intel.com>
Cc: Daniel Sanders <daniel_l_sanders at apple.com>; 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 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
--------------------------------------------------------------
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.


More information about the llvm-dev mailing list