On Oct 26, 2025, Jeff Law <[email protected]> wrote:

> Fundamentally we can't know if things work until link time, right,

*nod*

> I'd be inclined say these things aren't well defined in the smaller
> code models.  If we can do something that works reliably and is
> efficient, then great, otherwise I'd be inclined to punt.

I'm not sure I see grounds to label the addition of two well-defined
unsigned integers as 'not well defined', especially when the user can't
reliably(*) disable the optimization that makes a problem out of this
operation.

(*) without resorting to arcane magic such as e.g. extended asm to hide
the offset value from the compiler and force it into a separate
register.

That said, I acknowledge that testcases feel mostly artificially crafted
so as to trigger the problem, even if the outcome is quite likely with
default linker scripts that place .text before .data, so any data symbol
plus INT_MAX will be out of range for auipc from any point in the text
segment.

OTOH, the uses of the INT_MAX constant in testcases from the duped PRs
114168 and 117460, that get added to data symbols because of loop IV
optimizations, don't seem artificial to me.  It looks like reasonable
code to me, not something we could respond to with "don't do that then".

Which brings us to my proposed solution, of clipping the range for cases
that are more likely than not to not fit, which should take care of such
worst-case boundaries without harming far-more-frequent smaller offsets.

The downside is that, even if you know the offset would be in range for
a faster and smaller code sequence, the compiler would silently separate
the offset.

So perhaps we're indeed better off punting to a visible error with an
arcane workaround.

> Is there a compelling case outside the BZ that's got you digging
> around in here ;-) ?

The testcase passed on to me was surprisingly similar to something that
was already present in bugzilla.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

Reply via email to