This is the mail archive of the
gcc-patches@gcc.gnu.org
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>
- Date: Tue, 28 Oct 2014 11:46:19 +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>
> >> > 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
architectures.
'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.
Matthew