Re: [RFC] rationale for systematic elimination of OP_SYMADDR instructions

From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] rationale for systematic elimination of OP_SYMADDR instructions
Date: Fri, 11 Aug 2017 00:16:18 +0200	[thread overview]
Message-ID: <CAExDi1QVzkOVRxe+mdsHEi4=wirRFKrO+UFRDH2498z43oZidw@mail.gmail.com> (raw)
In-Reply-To: <CANeU7QkJy-G4EXuJ94KBcmo3Bc0Pei0uQSTeYr-u4DxsSK==uQ@mail.gmail.com>

On Thu, Aug 10, 2017 at 5:01 PM, Christopher Li <sparse@chrisli.org> 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