"Steve Ellcey " <[email protected]> writes:
> While building newlib with -O2 -mips16 I ran into a problem with GCC
> aborting due to the compiler trying to execute '0 % 0' in
> mips16_unextended_reference_p. The problem was that the code checked
> for BLKmode and skipped the modulo operation in that case because
> GET_MODE_SIZE (BLKmode) is zero but it didn't check for VOIDmode whose
> size is also zero. Rather then add a check for VOIDmode I changed
> the check to 'GET_MODE_SIZE (mode) != 0'.
>
> While looking at the code I also noticed that if offset was zero then
> we should return true even if mode is BLKmode or VOIDmode. Returning
> false would not generate bad code or cause problems but returning true
> would result in better costing model in mips_address_insns so I made
> that change too.
This came in with the recent change to pass the mode to address_cost.
I hadn't realised when asking for the associated mips_address_cost change
that address_cost sometimes gets passed VOIDmode.
mips_address_insns shouldn't have to deal with VOIDmode. The quick
hack I'd been using locally is to add:
if (mode == VOIDmode)
mode = SImode;
to mips_address_cost, which restores the previous behaviour for this case.
But the documentation says:
This hook is never called with an invalid address.
Since VOIDmode MEMs aren't valid, I think that should mean it's invalid
to call this hook (and rtlanal.c:address_cost) with VOIDmode. I never
got time to look at that though. (The culprit in the case I saw was
tree-ssa-loop-ivopts.c. Sandra had some improvements in this area,
so maybe they would fix this too.)
Loading or storing BLKmode doesn't map to any instruction, so I don't
think returning true for zero is any better than what we do now.
Richard
