On Fri, 29 Aug 2025, Jakub Jelinek wrote:
> 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.
Hmm, true.
> 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 thing is that to break a must-alias you only need a reg-reg copy ...
I would expect RTL scheduling to mess initialization/read order, but
then the read-only concern is not an issue anymore since we'd not
see any initialization for TREE_READONLY/MEM_READONLY_P. The asm
should prevent the re-ordering, it should act as a barrier for
any non-readonly object.
Richard.
