[llvm-dev] New intrinsic property IntrOnlyWrite

[Mehdi Amini via llvm-dev]

> 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