https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #17 from Wilco ---
Here is the current medium code model proposal:
https://github.com/ARM-software/abi-aa/pull/107/files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #15 from Wilco ---
(In reply to Bu Le from comment #14)
> > > Anyway, my point is that the size of single data does't affact the fact
> > > that
> > > medium code model is missing in aarch64 and aarch64 is lack of PIC large
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #14 from Bu Le ---
> > Anyway, my point is that the size of single data does't affact the fact that
> > medium code model is missing in aarch64 and aarch64 is lack of PIC large
> > code model.
>
> What is missing is efficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #13 from Wilco ---
(In reply to Bu Le from comment #11)
>
> > You're right, we need an extra add, so it's like this:
> >
> > adrpx0, bar1.2782
> > movkx1, :high32_47:bar1.2782
> > add x0, x0, x1
> > add x0, x0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #12 from Wilco ---
(In reply to Bu Le from comment #10)
> > Fortran already has -fstack-arrays to decide between allocating arrays on
> > the heap or on the stack.
>
> I tried the flag with my example. The fstack-array seems cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #11 from Bu Le ---
> You're right, we need an extra add, so it's like this:
>
> adrpx0, bar1.2782
> movk x1, :high32_47:bar1.2782
> add x0, x0, x1
> add x0, x0, :lo12:bar1.2782
>
> > (By the way, the high32_47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #10 from Bu Le ---
> Fortran already has -fstack-arrays to decide between allocating arrays on
> the heap or on the stack.
I tried the flag with my example. The fstack-array seems cannot move the array
in the bss to the heap. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #9 from Wilco ---
(In reply to Bu Le from comment #7)
> (In reply to Wilco from comment #5)
> > (In reply to Bu Le from comment #0)
> >
> > Also it would be much more efficient to have a relocation like this if you
> > wanted a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #8 from Wilco ---
(In reply to Bu Le from comment #6)
> (In reply to Wilco from comment #4)
> > (In reply to Bu Le from comment #3)
> > > (In reply to Wilco from comment #2)
>
> > Well the question is whether we're talking about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #7 from Bu Le ---
(In reply to Wilco from comment #5)
> (In reply to Bu Le from comment #0)
>
> Also it would be much more efficient to have a relocation like this if you
> wanted a 48-bit PC-relative offset:
>
> adrpx0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #6 from Bu Le ---
(In reply to Wilco from comment #4)
> (In reply to Bu Le from comment #3)
> > (In reply to Wilco from comment #2)
> Well the question is whether we're talking about more than 4GB of code or
> more than 4GB of data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #5 from Wilco ---
(In reply to Bu Le from comment #0)
Also it would be much more efficient to have a relocation like this if you
wanted a 48-bit PC-relative offset:
adrpx0, bar1.2782
add x0, x0, :lo12:bar1.2782
movkx0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #4 from Wilco ---
(In reply to Bu Le from comment #3)
> (In reply to Wilco from comment #2)
>
> > Is the main usage scenario huge arrays? If so, these could easily be
> > allocated via malloc at startup rather than using bss. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #3 from Bu Le ---
(In reply to Wilco from comment #2)
> Is the main usage scenario huge arrays? If so, these could easily be
> allocated via malloc at startup rather than using bss. It means an extra
> indirection in some cases (to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #1 from Bu Le ---
Created attachment 48585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48585=edit
patch for binutils
18 matches
Mail list logo
