[llvm-dev] RFC: Opaque pointer status and future direction

[Nicolai Hähnle via llvm-dev]

Hi Tim,

I very much like this. One note:

On Wed, Dec 18, 2019 at 4:16 PM Tim Northover via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Short term (because otherwise we can't do it for another six months):
> 1. Add inalloca(<ty>) support.
> 2. Document for January release the planned removal of:
>   * Old style byval
>   * Old style inalloca
>   * Typeless CreateCall, CreateLoad, CreateGEP.
> 3. Soon after January branch, strip out those bits. The third in
> particular should prevent front-end regression, I had to fix a fair
> few new deprecated callsites in Clang when rebasing everything this
> week.

Can we please have a transition period where those Create* functions
are marked as LLVM_ATTRIBUTE_DEPRECATED? And same for the
corresponding C API functions. This would be tremendously helpful for
out-of-tree frontends that track master.

This transition period doesn't necessarily have to be long. As far as
I'm concerned it wouldn't even have to be a full release cycle, though
others might disagree. But keeping those methods around as explicitly
deprecated (in a way that causes compiler noise so that it doesn't get
missed!) for a month or two would be good.


> Short/medium term:
>
> 1. Commit serialization and Instruction changes.
> 2. Use that to add tests for patches I already have and upstream them.
> 3. Keep fixing the issues, but no-one not working on opaque pointers should need
>    to change their behaviour other than a general encouragement to not use
>    getElementType unless they have to.

I think "general encouragement" is too weak here. Getting rid of
getPointerElementType() seems to me the hardest piece of the puzzle
because it creates architectural issues in a lot of different places.
For example, I noticed that some of the sanitizers lean on being able
to use this function, and this cannot be fixed locally in just the
backend sanitizer implementation. Our own AMDGPU backend also has some
issues like that, and I'd expect that more are lurking somewhere.

Most getPointerElementType() uses seem to be fairly harmless and
fixable locally, but we need a stronger lever to get those
architectural issues fixed.

Cheers,
Nicolai


>
> Long term:
>
> As we get close to everything working, we should shift the expectations so that
> new uses of getElementPtr aren't allowed in LLVM.
>
> Front-ends (including Clang) will need more work I suspect.
>
> No doubt there will be performance issues where having a pointee type helps some
> heuristic be a bit better. We'll have to decide what to do about those.
>
> [0] See attached opaque.ll for some proposed IR.
> [1] See attached asserts.txt if interested.
> [2] Or perhaps more likely documented with "don't use it unless you're working
> on opaque pointers" warnings.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.