llvm dev - Mar 2016 - New intrinsic property IntrOnlyWrite

On 19.03.2016 16:25, Mehdi Amini wrote:
> Hi,
>
> Can you elaborate what is the impact at the IR level?
> If the point is just about how you lower for you target, why are you
needing an IR level attribute? You backend if free to specialize the lowering
for any intrinsic regardless the IR level attributes.
As I explained in my reply to Philip, what I really need is a way to get 
TableGen to shut up about what it reasonably believes to be a mismatch 
between the properties of the intrinsic (which it conservatively 
believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the 
hardware instruction (which is correctly mayLoad = 0, mayStore = 1, 
hasSideEffects = 0).

Indeed, write-only without an ArgMemOnly property may well be useless at 
the IR level. If you think that there is a better way to explain the 
situation to TableGen, please let me know.

Please see my mail to Philip for a more detailed explanation for why we 
are in this situation.

Thanks,
Nicolai

> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com>
wrote:
> 
> On 19.03.2016 16:25, Mehdi Amini wrote:
>> Hi,
>> 
>> Can you elaborate what is the impact at the IR level?
>> If the point is just about how you lower for you target, why are you
needing an IR level attribute? You backend if free to specialize the lowering
for any intrinsic regardless the IR level attributes.
> 
> As I explained in my reply to Philip, what I really need is a way to get
TableGen to shut up about what it reasonably believes to be a mismatch between
the properties of the intrinsic (which it conservatively believes to be mayLoad
= 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is
correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0).
I'm not sure what is the semantics of "hasSideEffects" at the MI
level. I'm surprised we can consider correct that something that writes to
memory is not "having side effects".

At the IR level, the definition of "mayHaveSideEffects" is more
coherent with what I expect:

  bool mayHaveSideEffects() const {
    return mayWriteToMemory() || mayThrow() || !mayReturn();
  }
> Indeed, write-only without an ArgMemOnly property may well be useless at
the IR level. If you think that there is a better way to explain the situation
to TableGen, please let me know.
I don't really understand why an MI which is "mayLoad" would have
a side effect?
I don't get either why not an MI which is "mayStore" would not
have a side effect. I'd expect that mayStore imply "hasSideEffect"
(i.e. the latter being a strict superset).
(but hey, I'm not an MI expert and I'd need some clarification on the
implication of "hasSideEffect" at the MI level)

-- 
Mehdi

> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at
gmail.com> wrote:
>> 
>> On 19.03.2016 16:25, Mehdi Amini wrote:
>>> Hi,
>>> 
>>> Can you elaborate what is the impact at the IR level?
>>> If the point is just about how you lower for you target, why are
you needing an IR level attribute? You backend if free to specialize the
lowering for any intrinsic regardless the IR level attributes.
>> 
>> As I explained in my reply to Philip, what I really need is a way to
get TableGen to shut up about what it reasonably believes to be a mismatch
between the properties of the intrinsic (which it conservatively believes to be
mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction
(which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0).
> 
> I'm not sure what is the semantics of "hasSideEffects" at the
MI level. I'm surprised we can consider correct that something that writes
to memory is not "having side effects".
> 
> At the IR level, the definition of "mayHaveSideEffects" is more
coherent with what I expect:
> 
>  bool mayHaveSideEffects() const {
>    return mayWriteToMemory() || mayThrow() || !mayReturn();
>  }
> 
>> Indeed, write-only without an ArgMemOnly property may well be useless
at the IR level. If you think that there is a better way to explain the
situation to TableGen, please let me know.
> 
> I don't really understand why an MI which is "mayLoad" would
have a side effect?
> I don't get either why not an MI which is "mayStore" would
not have a side effect. I'd expect that mayStore imply
"hasSideEffect" (i.e. the latter being a strict superset).
> (but hey, I'm not an MI expert and I'd need some clarification on
the implication of "hasSideEffect" at the MI level)
The MI level talks about side effects not modeled by any other mechanism
(MCInstrDesc::hasUnmodeledSideEffects()) which is more useful than a
conservative as we can differentiate between effects of memory read/writes (to
possible known addresses) and arbitrary things (like wait for input, write to
device, ...).

- Matthias

> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at
gmail.com> wrote:
>> 
>> On 19.03.2016 16:25, Mehdi Amini wrote:
>>> Hi,
>>> 
>>> Can you elaborate what is the impact at the IR level?
>>> If the point is just about how you lower for you target, why are
you needing an IR level attribute? You backend if free to specialize the
lowering for any intrinsic regardless the IR level attributes.
>> 
>> As I explained in my reply to Philip, what I really need is a way to
get TableGen to shut up about what it reasonably believes to be a mismatch
between the properties of the intrinsic (which it conservatively believes to be
mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction
(which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0).
> 
> I'm not sure what is the semantics of "hasSideEffects" at the
MI level. I'm surprised we can consider correct that something that writes
to memory is not "having side effects".

Answer to myself, I finally found the MI API (thanks Matthias), and it is called
hasUnmodeledSideEffects. I think the "unmodeled" part of the name is
important here :)
Here is the doxygen:

  /// \brief Return true if this instruction has side
  /// effects that are not modeled by other flags.  This does not return true
  /// for instructions whose effects are captured by:
  ///
  ///  1. Their operand list and implicit definition/use list.  Register use/def
  ///     info is explicit for instructions.
  ///  2. Memory accesses.  Use mayLoad/mayStore.
  ///  3. Calling, branching, returning: use isCall/isReturn/isBranch.

Now you initially reported that "TableGen will (correctly) complain about a
mismatch of mayLoad and hasSideEffects", I believe this is incorrect
considering the above description.

-- 
Mehdi


> 
> At the IR level, the definition of "mayHaveSideEffects" is more
coherent with what I expect:
> 
>  bool mayHaveSideEffects() const {
>    return mayWriteToMemory() || mayThrow() || !mayReturn();
>  }
> 
>> Indeed, write-only without an ArgMemOnly property may well be useless
at the IR level. If you think that there is a better way to explain the
situation to TableGen, please let me know.
> 
> I don't really understand why an MI which is "mayLoad" would
have a side effect?
> I don't get either why not an MI which is "mayStore" would
not have a side effect. I'd expect that mayStore imply
"hasSideEffect" (i.e. the latter being a strict superset).
> (but hey, I'm not an MI expert and I'd need some clarification on
the implication of "hasSideEffect" at the MI level)
> 
> -- 
> Mehdi
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev