This is the mail archive of the
mailing list for the GCC project.
RE: [Patch] Add MIPS flag to avoid use of ldc1/sdc1/ldxc1/sdxc1
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Andrew Pinski <pinskia at gmail dot com>, "Moore, Catherine" <Catherine_Moore at mentor dot com>
- Cc: Steve Ellcey <Steve dot Ellcey at imgtec dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Raghu Gandham <Raghu dot Gandham at imgtec dot com>
- Date: Tue, 28 Oct 2014 21:06:48 +0000
- Subject: RE: [Patch] Add MIPS flag to avoid use of ldc1/sdc1/ldxc1/sdxc1
- Authentication-results: sourceware.org; auth=none
- References: <4f0faaab-5dd4-40c8-b66d-feb9bb515c0d at BAMAIL02 dot ba dot imgtec dot org> <CA+=Sn1=STsjh2pms1Sp=a05jji=ck9hYJKYjGH3KM9GDmC+vhg at mail dot gmail dot com> <FD3DCEAC5B03E9408544A1E416F11242016E7592D0 at NA-MBX-04 dot mgc dot mentorg dot com> <CA+=Sn1=wpxqyw_prTs-v_yZ47yhrRqWs_CobvgtCcrEKT4VJXA at mail dot gmail dot com> <FD3DCEAC5B03E9408544A1E416F11242016E75930A at NA-MBX-04 dot mgc dot mentorg dot com> <CA+=Sn1nYbc=3ZqV6g_4q27cug_z9759vFFVHk9zBg4OSj9bntQ at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320F344E8 at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <email@example.com> writes:
> > >> > Do you have an objection to allowing an option to disable these
> > >> instructions (despite the reason for wanting to do so)?
> > >>
> > >> Yes this seems like a bad workaround for broken code.
> > >>
> > > Well, we work around broken hardware all the time. What would you
> > suggest that Steve do instead?
> > We work around broken hardware all the time yes but that is something
> > which is hard to change. Software is easier to fix. That does not
> > mean in the compiler. The compiler team should not get themselves in
> > the business of working around broken software that depends on
> > undefined behavior (this undefined behavior is very obvious and easier
> > to fix in the source of the problem). Report the bug to Google.
> I'm mostly in agreement with Andrew on this. I'd like to understand more
> about the use-case and what happens for other architectures (only ARM
> and x86 are really relevant here I guess). I believe x86 will just
> happily load/store doubles to 4-byte aligned addresses but I'm not sure
> for ARM. If ARM has to take unaligned access faults for this then I
> think MIPS simply has to do the same.
> Unless the application is allocating thousands of small chunks of data
> and the padding is significant in the overall memory usage then I'd have
> thought the allocator could be fixed relatively easily. I'd also expect
> that to be generally a performance win for the application on all
> 'If' we were to make a change to the compiler then I would make it a
> little more generic/focus on the actual issue which relates to alignment.
> I'm not sure what I would call the option but its effect would be for
> the compiler to not rely on any greater than 'X' alignment and disable
> the use of any load/store instructions which need larger alignment.
> That still feels like a bad feature though.
Opinions aside there are actually some technical problems with this
feature. In particular we have to consider that the o32 ABI is about to
start its long awaited transition to use 64-bit floating-point registers.
We know that removing LDC1/SDC1 is possible for the original O32 FP32 ABI
as doubles just get handled with pairs of LWC1/SWC1.
Now if we consider O32 FP64 then it is not possible to use LWC1 to access
the upper-32-bits of doubles but we do have MTHC1/MFHC1 so the data would
have to move via GPRs which doubles the penalty in a way as GPR-FPR
transfers are generally slow. (I think the patch as it stands will fail
if used with O32 FP64 but I haven't looked in detail)
The bigger problem comes from the transitional ABI O32 FPXX. Firstly,
O32 FPXX on MIPS32r2 onwards... this will be OK as it has MTHC1/MFHC1 so
can use the same solution as O32 FP64. Next, O32 FPXX on MIPS II... this
is simply impossible, there is no way to load a double-precision FPR
given the constraints of the O32 FPXX ABI and the removal of LDC1/SDC1.
While the patch could be fixed to account for all of this we need to
determine if the case which won't work is the exact one which is needed
(and I believe it is). I.e. Android applications for MIPS are MIPS32r1
O32 FP32 NAN1985 currently and will transition from FP32 to FPXX to
enable the use of things like MSA. Since MIPS32r1 does not have
MTHC1/MFHC1 then this solution will not work.
We'll have to talk with the google engineers to explain the issues.