On Fri, Aug 29, 2025 at 10:15:33AM +0200, Richard Biener wrote:
> On Fri, 29 Aug 2025, Richard Biener wrote:
>
> > On Fri, 29 Aug 2025, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > Here is a variant of the patch which pretends there are also stores
> > > in the inline asms.
> > > Plus the forgotten std.cc exports.
> >
> > Can you add a testcase on actual constant objects? I wonder why
> > we do not diagnose asm outputs on such?
>
> In particular I wonder about
>
> void foo(int n)
> {
> const short a[8] = { 1,2,3,4,5,6,7,8 };
> int sum = 0;
> for (int i = 0; i < n; ++i)
> {
> const int *p = std::start_lifetime_as<int> (a);
> sum += ((int *)a)[2];
> }
> return sum;
> }
>
> I'd expect RTL LIM to hoist the ((int *)a)[2] load across the asm()
> as 'a' is readonly. GIMPLE alias analysis of course treats all
> asm()s with a VDEF as black-boxes.
If it is just const var, then I don't think it is TREE_READONLY
or MEM_READONLY_P because it needs to be initialized.
And if it is static const, don't we treat mustalias TBAA violations
as type punning? I.e. aren't the only problem may aliases, but that
would mean using p (which code should better do anyway) and in that
case optimizers don't know where p points to (unless in p == a
is asserted or tested, but then it would be again mustalias?).
> The hoisting would be a TBAA violation, possibly wrong-code if 'a'
> is put on the stack.
Jakub
