[PATCH] D11577: Reassociate: Implement isUnmovableInstruction() without a hardcoded list

[Daniel Berlin]

????

I'm not thinking in that dichotomy, that is the generally  dichotomy
of dependences in compilers :).

Data dependence talks about memory all the time, in compiler
schedulers, in loop data dependence, etc.  Heck, even in SSA.
So I honestly do not grasp the distinction you are trying to draw here.

It happens that in LLVM, explicitly represented data dependences do
not make instructions inherently immovable.  The IR explicitly
represents these things well enough that we don't pay a high cost for
figuring out safe move locations for those things.

However, memory data dependences are implicit (becuase we lack
something like memoryssa), and the cost of figuring out where the safe
move points are is not worth it.
(IE none of these instructions are actually immovable, it's just that
we don't want to pay the cost to figure out the place we could move
them to :P. For some of them, there is usually only one correct place
anyway, like phi nodes.  )

Not to bikeshed this too hard, but state dependent means nothing to
me, and it doesn't actually give anyone any idea what the function
should return for what.



On Wed, Jul 29, 2015 at 2:52 PM, Matthias Braun <matze at braunis.de> wrote:
> MatzeB added a comment.
>
> In http://reviews.llvm.org/D11577#214574, @dberlin wrote:
>
>> So, these are either data dependent, control dependent, or both :)
>>  (IE that is the correct terminology)
>
>
> If you think in that dichotomy, then it is a data dependence. However usually data dependence talks about variables or registers while this function specifically is about the things not modeled as variables/ssa values. It is about the global state/memory, that's why I put the "State" in the name data dependence would be too broad.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D11577
>
>
>