[PATCH] D144190: [AIX][clang] Storage Locations for Constant Pointers

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.


================
Comment at: clang/test/Driver/ppc-roptr.c:10
+// ROPTR-NOT: "-mroptr"
+// ROPTR-NOT: "-bforceimprw"
+
----------------
hubert.reinterpretcast wrote:
> w2yehia wrote:
> > hubert.reinterpretcast wrote:
> > > Do we pass the option through to the LTO codegen when `-fprofile-generate` is used?
> > > We may need a driver diagnostic for `-mroptr` without data sections when linking LTO objects (because the front-end won't be involved).
> > > 
> > > @w2yehia, does LLVM trunk have a gap in LTO driver enablement for AIX?
> > > does LLVM trunk have a gap in LTO driver enablement for AIX?
> > 
> > I think trunk is up to date in terms of LTO (driver and libLTO); this was done in LLVM 16.0.
> > 
> > > Do we pass the option through to the LTO codegen when -fprofile-generate is used?
> > 
> > what's special with  -fprofile-generate in relation to the ROPTR option?
> Sorry, I meant on the LTO link step.
It seems to me that we don't pass the option through to the LTO codegen on the LTO link step (which is a problem).

It also seems that there is no diagnostic generated (would likely hit the back-end assertion/error) when `-fno-data-sections` and `-mroptr` is specified at the same time for the LTO link step. I believe a driver diagnostic needs to be added.

I am of the opinion that we don't have to have a front-end diagnostic in addition to a driver diagnostic if the back-end will error out in the case where relevant codegen is encountered (it provides an esoteric way to quickly check if relevant codegen is involved for a given source file). We should apply the same policy between `clang -cc1` and `llc` though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144190/new/

https://reviews.llvm.org/D144190