This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [Patch] Add MIPS flag to avoid use of ldc1/sdc1/ldxc1/sdxc1

> >> >   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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]