Re: Question for maintainers: ARCv3 port feasibility
On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs wrote: > > Dear GCC Maintainers and Steering Committee, > > I'm currently doing a feasibility study and effort estimate for > upstreaming the existing ARCv3 out-of-tree port [1]. > > Question: Is there likely to be any objection to adding a new "arc64" > port in addition to the existing "arc" port? I don't see any strong reason not to do this, assuming 'arc' is 32bit only and 'arc64' is a 64bit CPU. But I'd say the arc port maintainer should weight in (CCed). Technically the SC has to accept a new port I think. Richard. > At this point, I would like to check that the general approach is likely > to be accepted at the end of the project. Or, at least not rejected for > this most fundamental of reasons. > > The ARCv3 port has been written as a new backend because it is not just > a simple evolution of the ARC architecture and starting afresh made more > sense to the developers at the time. I'm aware that there are some > precedents for this (sh64, ia64, aarch64), so I think it's probably > fine, right? > > If necessary, I can do a closer analysis of the two ports and figure out > how to unify them, but of course that's going to take longer and cost more. > > Any advice would be appreciated. > > Thanks very much, > > Andrew > > > [1] https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc64
Question for maintainers: ARCv3 port feasibility
Dear GCC Maintainers and Steering Committee, I'm currently doing a feasibility study and effort estimate for upstreaming the existing ARCv3 out-of-tree port [1]. Question: Is there likely to be any objection to adding a new "arc64" port in addition to the existing "arc" port? At this point, I would like to check that the general approach is likely to be accepted at the end of the project. Or, at least not rejected for this most fundamental of reasons. The ARCv3 port has been written as a new backend because it is not just a simple evolution of the ARC architecture and starting afresh made more sense to the developers at the time. I'm aware that there are some precedents for this (sh64, ia64, aarch64), so I think it's probably fine, right? If necessary, I can do a closer analysis of the two ports and figure out how to unify them, but of course that's going to take longer and cost more. Any advice would be appreciated. Thanks very much, Andrew [1] https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc64
Target hook TARGET_MODES_TIEABLE_P
Hi all,
On s390 we only tie floating-point modes SF and DF, and then all
remaining ones:
static bool
s390_modes_tieable_p (machine_mode mode1, machine_mode mode2)
{
return ((mode1 == SFmode || mode1 == DFmode)
== (mode2 == SFmode || mode2 == DFmode));
}
This in turn leads sometimes to higher costs as e.g. in
(set (reg:SI 60 [ _2 ])
(lshiftrt:SI (subreg:SI (reg/v:SF 62 [ xD.3041 ]) 0)
(const_int 31 [0x1f])))
original cost = 4 (weighted: 4.00), replacement cost = 16 (weighted:
16.00); rejecting replacement
due to rtx_costs()
case SUBREG:
total = 0;
/* If we can't tie these modes, make this expensive. The larger
the mode, the more expensive it is. */
if (!targetm.modes_tieable_p (mode, GET_MODE (SUBREG_REG (x
return COSTS_N_INSNS (2 + factor);
>From the internals handbook I see the strong connection between
TARGET_MODES_TIEABLE_P and TARGET_HARD_REGNO_MODE_OK which I kinda read
as
forall m1, m2. forall r.
(TARGET_HARD_REGNO_MODE_OK (r, m1) == TARGET_HARD_REGNO_MODE_OK (r, m2))
=> TARGET_MODES_TIEABLE_P (m1, m2)
Since on s390 a value which is stored in any GPR/FPR/VR can be retrieved
unmodified, i.e., there is no normalization happening in FPRs/VRs or
whatsoever, we could actually lift this to something along the line:
static bool
s390_modes_tieable_p (machine_mode mode1, machine_mode mode2)
{
if (GET_MODE_CLASS (mode1) == MODE_CC)
return GET_MODE_CLASS (mode2) == MODE_CC;
if (TARGET_VX && GET_MODE_SIZE (mode1) <= 8 && GET_MODE_SIZE (mode2) <= 8)
return true;
return ((mode1 == SFmode || mode1 == DFmode)
== (mode2 == SFmode || mode2 == DFmode));
}
since any value up to 8 bytes can be stored/retrieved in any GPR/FPR/VR, if
vector extensions are available.
However, what makes me a little bit cautious is that this is true for a lot of
targets but different TARGET_MODES_TIEABLE_P implementations are rather
involved which makes me wonder whether I missed something here. Especially
since riscv even does not allow modes SF and DF to be tied in contrast to s390:
Don't allow floating-point modes to be tied, since type punning of
single-precision and double-precision is implementation defined.
Furthermore, the last sentence in the paragraph:
If TARGET_HARD_REGNO_MODE_OK (r, mode1) and TARGET_HARD_REGNO_MODE_OK (r,
mode2) are always the same for any r, then TARGET_MODES_TIEABLE_P (mode1,
mode2) should be true. If they differ for any r, you should define this hook to
return false unless some other mechanism ensures the accessibility of the value
in a
narrower mode.
speaks about narrower mode which rather increases my concerns about the
potential new implementation of s390_modes_tieable_p().
Last but not least, having a look at TARGET_MODES_TIEABLE_P usages we have e.g.
in combine.cc:
/* In general, don't install a subreg involving two
modes not tieable. It can worsen register
allocation, and can even make invalid reload
insns, since the reg inside may need to be copied
from in the outside mode, and that may be invalid
if it is an fp reg copied in integer mode.
Since on s390 FPRs are left aligned and GPRs are right aligned, I can imagine
that a (subreg:DI (reg:SF 65 [ xD.3041 ]) 0) could lead to problems as
described in the comment. During my experiments I have seen such subregs,
though, those were all dealt with correctly but maybe I was just lucky.
Long story short, could someone shed some light on hook
TARGET_MODES_TIEABLE_P, or does anyone see a potential problem by tying
all modes with size less than or equal to 8 bytes as long as we have
proper mov insns?
Cheers,
Stefan
GCC 14.2.1 Status Report (2025-05-15), branch frozen for release
Status == The GCC 14 branch is now frozen for the GCC 14.3 release, a release candidate is being prepared. All changes to the branch require release manager approval. Previous Report === https://gcc.gnu.org/pipermail/gcc/2025-April/245990.html
GCC 14.3 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 14.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/14.3.0-RC-20250515/ ftp://gcc.gnu.org/pub/gcc/snapshots/14.3.0-RC-20250515/ and shortly its mirrors. It has been generated from git commit r14-11789-gaa4cd614456de6. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd like to release 14.3 on Friday, May 23th.
gcc-13-20250515 is now available
Snapshot gcc-13-20250515 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20250515/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 9ad74a57904744418a7319a492a698ddbfb787ca You'll find: gcc-13-20250515.tar.xz Complete GCC SHA256=9a8a7f090eba6f842fa028f124ce194bfdbbe5e52d89101f9b9df2ea2953a1f5 SHA1=0aa599ab6fc3565f27884c3c928186d58020b551 Diffs from 13-20250508 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question for maintainers: ARCv3 port feasibility
Hi, On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote: > Dear GCC Maintainers and Steering Committee, > > I'm currently doing a feasibility study and effort estimate for > upstreaming the existing ARCv3 out-of-tree port [1]. > > Question: Is there likely to be any objection to adding a new "arc64" > port in addition to the existing "arc" port? > > At this point, I would like to check that the general approach is likely > to be accepted at the end of the project. Or, at least not rejected for > this most fundamental of reasons. > > The ARCv3 port has been written as a new backend because it is not just > a simple evolution of the ARC architecture and starting afresh made more > sense to the developers at the time. I'm aware that there are some > precedents for this (sh64, ia64, aarch64), so I think it's probably > fine, right? > SH5/SH64 was actually part of the original SH port, not a separate standalone port. It made the port more complex and convoluted, but probably made sense since the it was backwards compatible with the original SH ISA (it was like ARM Thumb -- jump to select between classic SH ISA and new SH5 ISA, from what I remember). Best regards, Oleg Endo
Re: Question for maintainers: ARCv3 port feasibility
> On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc wrote:
>
> Hi,
>
> On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote:
>> Dear GCC Maintainers and Steering Committee,
>>
>> I'm currently doing a feasibility study and effort estimate for
>> upstreaming the existing ARCv3 out-of-tree port [1].
>>
>> Question: Is there likely to be any objection to adding a new "arc64"
>> port in addition to the existing "arc" port?
>>
>> At this point, I would like to check that the general approach is likely
>> to be accepted at the end of the project. Or, at least not rejected for
>> this most fundamental of reasons.
>>
>> The ARCv3 port has been written as a new backend because it is not just
>> a simple evolution of the ARC architecture and starting afresh made more
>> sense to the developers at the time. I'm aware that there are some
>> precedents for this (sh64, ia64, aarch64), so I think it's probably
>> fine, right?
>>
>
> SH5/SH64 was actually part of the original SH port, not a separate
> standalone port. It made the port more complex and convoluted, but probably
> made sense since the it was backwards compatible with the original SH ISA
> (it was like ARM Thumb -- jump to select between classic SH ISA and new SH5
> ISA, from what I remember).
>
> Best regards,
> Oleg Endo
Also: ia64 is a separate ISA. If you were thinking about x86-64, that's part
of i386 ("ia-32"). Similarly, "mips" is both flavors (and all four ABIs). So
there are several examples in both directions.
paul
