[llvm-dev] New intrinsic property IntrOnlyWrite

[Mehdi Amini via llvm-dev]

> 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