[Bug target/108208] New: Build failure on large LLVM source files on PPC

[Bug target/108208] New: Build failure on large LLVM source files on PPC

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

            Bug ID: 108208
           Summary: Build failure on large LLVM source files on PPC
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sam at gentoo dot org
  Target Milestone: ---

We've seen this a few times in Gentoo when building LLVM, but this is the
latest case.

```
$ gcc --version
gcc (Gentoo 13.0.0_pre20221218 p5) 13.0.0 20221218 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

```
/usr/bin/c++ -save-temps -O2 -g -pipe -fsanitize=undefined -std=c++17 -fPIC
-fno-semantic-interposition -fvisibility-inlines-hidden -ffunction-sections
-fdata-sections  -fno-exceptions -fno-rtti RegisterInfoEmitter.cpp.ii
[...]
a-RegisterInfoEmitter.cpp.s:577996: Error: operand out of range
(0x0000000000009d8c is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578007: Error: operand out of range
(0x0000000000009d10 is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578016: Error: operand out of range
(0x0000000000009d18 is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578024: Error: operand out of range
(0x0000000000009d14 is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578042: Error: operand out of range
(0x0000000000009d84 is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578061: Error: operand out of range
(0x0000000000009d5c is not between 0xffffffffffff8000 and 0x0000000000007fff)
a-RegisterInfoEmitter.cpp.s:578071: Error: operand out of range
(0x0000000000009d68 is not between 0xffffffffffff8000 and 0x0000000000007fff)
[...]
```

I've uploaded gcc-RegisterInfoEmitter-ppc.tar.xz at
https://dev.gentoo.org/~sam/bugs/gcc/gcc-RegisterInfoEmitter-ppc/gcc-RegisterInfoEmitter-ppc.tar.xz
(because of the size of the files) which contains:
```
-rw-r--r--  1 root root 2.8M Dec 23 10:35
gcc-RegisterInfoEmitter-ppc/RegisterInfoEmitter.cpp.ii
-rw-r--r--  1 root root  42M Dec 23 10:45
gcc-RegisterInfoEmitter-ppc/a-RegisterInfoEmitter.cpp.s
```

Minimising is hard because it only happens with large source files and it's
also time consuming to compile and get the error.

(Sorry for external link, it's too big even when compressed to attach here, as
it's 4MB.)

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #1 from Sam James <sam at gentoo dot org> ---
Ah, based on https://bugzilla.redhat.com/show_bug.cgi?id=427700#c3 &
https://bugzilla.redhat.com/show_bug.cgi?id=427700#c5, maybe the source really
does just need splitting.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-27
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Yes, agreed.  Marking this bug as invalid.

If you need a bigger code model you should use -mcmodel=large, or keep code
size under control some other way (using -O3 is a very bad idea in general;
it means "don't do tradeoffs, be overly optimistic always".  -O2 is perhaps
a bit too conservative, but -O3 definitely is too far out on the other side
of the spectrum.  Luckily there are many smaller tweak flags, and many params
you can fiddle with).

This is not a new problem at all.  The default code model we use is quite
conservative, but it is not very hard to overflow its limits.  You usually
get much better (smaller as well as faster) generated code by writing better
source code, dividing it up into translation units a bit smarter.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glaubitz at physik dot fu-berlin.d
                   |                            |e

--- Comment #3 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I am seeing this when building LLVM and GHC on 32-bit PowerPC as well. It does
not affect other 32-bit architectures and using LLVM as the bootstrap compiler
resolves this issue.

What's the proper way of addressing this?

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
See my previous comment?

You can either write better code, or use -mcmodel=large or similar, accepting
the not-so-stellar generated code you get then.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #5 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Segher Boessenkool from comment #4)
> See my previous comment?
> 
> You can either write better code, or use -mcmodel=large or similar, accepting
> the not-so-stellar generated code you get then.

I'm already testing -mcmodel=large now. I'm just surprised it just affects GCC
on PowerPC but not LLVM, for example.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #6 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > See my previous comment?
> > 
> > You can either write better code, or use -mcmodel=large or similar, accepting
> > the not-so-stellar generated code you get then.
> 
> I'm already testing -mcmodel=large now. I'm just surprised it just affects
> GCC on PowerPC but not LLVM, for example.

Doesn't seem to be supported, unfortunately, build fails with:

'-mcmodel' not supported in this configuration

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.

Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-*
configurations.
Some other architectures have it for more things, and some for fewer, or even
none.

If you get an error at line 577996 of a source file, changes are your code is
just
completely unreasonably large, esp. on a smaller target like this :-)

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #8 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Segher Boessenkool from comment #7)
> This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.

Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"?

> Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-*
> configurations.
> Some other architectures have it for more things, and some for fewer, or
> even none.

I am trying -O3 now.

> If you get an error at line 577996 of a source file, changes are your code
> is just
> completely unreasonably large, esp. on a smaller target like this :-)

I understand. But it's not always possible to change the code size, especially
when the code is not mine but some random upstream code.

What I don't understand is that other 32-bit architectures don't seem to be
affected. For example, hppa-unknown-linux-gnu is not affected.

And, secondly, using LLVM as the bootstrap compiler resolves the issue with
LLVM for me.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.
> 
> Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"?

Yes.  And most of the discussion (via the gentoo link) is about
powerpc64-linux.

So things were confusing, for me at least.

> I am trying -O3 now.

That almost always runs out of space easier, not less easily.  O3 prioritises
possible speed wins over anything else (*possible* speed wins).

> > If you get an error at line 577996 of a source file, changes are your code
> > is just
> > completely unreasonably large, esp. on a smaller target like this :-)
> 
> I understand. But it's not always possible to change the code size,
> especially when the code is not mine but some random upstream code.
> 
> What I don't understand is that other 32-bit architectures don't seem to be
> affected. For example, hppa-unknown-linux-gnu is not affected.

None of the HPPA ABIs are affected by peculiarities of a particular PowerPC
ABI.

The bug report does noty give enough information to see what is really going
on,
so I have no further advice.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to John Paul Adrian Glaubitz from comment #8)
> > (In reply to Segher Boessenkool from comment #7)
> > > This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.
> > 
> > Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"?
> 
> Yes.  And most of the discussion (via the gentoo link) is about
> powerpc64-linux.
> 
> So things were confusing, for me at least.

OK, yeah. That's confusing. I haven't seen any issues on 64-bit targets.

> > I am trying -O3 now.
> 
> That almost always runs out of space easier, not less easily.  O3 prioritises
> possible speed wins over anything else (*possible* speed wins).

This actually worked for me and allowed me to build an unregisterised GHC
compiler. So, thanks for the hint!

> > > If you get an error at line 577996 of a source file, changes are your code
> > > is just
> > > completely unreasonably large, esp. on a smaller target like this :-)
> > 
> > I understand. But it's not always possible to change the code size,
> > especially when the code is not mine but some random upstream code.
> > 
> > What I don't understand is that other 32-bit architectures don't seem to be
> > affected. For example, hppa-unknown-linux-gnu is not affected.
> 
> None of the HPPA ABIs are affected by peculiarities of a particular PowerPC
> ABI.

OK, I see.

> The bug report does noty give enough information to see what is really going
> on,
> so I have no further advice.

Your pointer towards -O3 did the trick, so no worries!