On Thu, Aug 10, 2017 at 5:01 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote:
>
> Please correct me if I am wrong. I still think:
> 1) OP_SYMADDR can be generated from the symbol node and where
> to place them (immediate D(N)).
>
> 2) If one of the back end needs them. Go ahead and generate OP_SYMADDR.
> However, I don't think sparse checker need to use the OP_SYMADDR
> so it will be more optimal for sparse checker to avoid OP_SYMADDR.
>
> Am I missing some thing?
I'm not sure to understand exactly what you mean here above, sorry.
But yes, I think you're missing something.
All this have already been explained during the initial discussion but:
* those OP_SYMADDR represent the *calculation* that is needed to get
the address of a symbol.
* depending on the architecture, the kind/linkage/visibility of the symbol,
compiler flag, ... this calculation can be very simple, like:
- just a constant (but a big one)
- just a load at a constant address & a constant address
- or much more complicated
* the OP_SYMADDR *abstract* away the *details* of this calculation
but it is important to expose it
* of the reasons we want to expose it is that we *want* to do CSE on
these calculations
* there is absolutely no reasons why we should process them differently
than any other instructions. In particular, it would be absurd to:
- try to put all of them at the top
- try to place them ourself at some other special place (common parent,
dominator, ...)
because CSE will place them automatically at the best place: as near as
possible from where they are needed.
* it would also be a very bad idea to *not* generate them and only let the
backend generate them because it would then mean that iether:
- no CSE on them
- backend need to reimplement CSE for them
The backend, just need to *expose the details*, maybe change those
SYMADDR in the appropriate loads & adds & loads or whatever but
they need to be already there and processed by the middle-end.
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
