[llvm-dev] Using TBAA type descriptor's name as hints for optimizations

David Chisnall via llvm-dev
Wed, 28 Apr 2021 16:11:36 -0000

Hi,

I think it's clear that using TBAA or anything else for *hinting*
optimisation is fine.  The discussion in the review was rooted in two
problems:

  - In some cases the transform is not valid.  `memcpy` must be a
type-oblivious copy.  On some platforms (e.g. CHERI, including Arm's
Morello, and with some language VMs), turning these into a typed
load-store is not valid.  We lose tracking of pointers in these
environments.  It is *always* valid to delete metadata and an
optimisation may not become unsound if metadata is elided.

  - The transform was introducing things that made later analyses worse
and so was not improving the optimisation pipeline overall.

Of these, the first is more significant.  If a transform is valid in the
absence of metadata and generates better code in the presence of
metadata, this is fine (and follows from the description of metadata in
the LangRef today).  If an optimisation becomes unsound when metadata is
omitted, this is categorically incorrect.

I don't object to the clarification in the LangRef, but all of this
follows from the general rules about metadata:

  - Removing all metadata from a module should not cause miscompilations.

  - Adding metadata may alter code generation in any way that does not
violate the extra semantics defined by the metadata.

David

On 23/04/2021 19:03, Juneyoung Lee via llvm-dev wrote:
> Hello all,
>
> There was a discussion (https://reviews.llvm.org/D100717
> <https://reviews.llvm.org/D100717>) about whether using TBAA type
> descriptor metadata's type name as hints for optimizations is okay.
>
> The patch is using the type name to determine whether converting memcpy
> to load/store of integer is beneficial or not.
> If the memcpy was copying a struct containing a pointer member, this
> becomes the source of a lot of inttoptr casts because the later store
> forwarding needs them.
> The introduced inttoptr casts are later removed by cast elimination
> (`inttoptr(ptrtoint p) -> p`), but there are issues (e.g.
> http://llvm.org/pr34548 <http://llvm.org/pr34548>) which is deeply
> related with its validity.
>
> A suggested clarification to LangRef is made at
> https://reviews.llvm.org/D101185 <https://reviews.llvm.org/D101185>
as
> well -
> feel free to leave comments here and there.
>
> Thanks,
> Juneyoung
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>