On 2/6/18 11:39 AM, Segher Boessenkool wrote:
> Yes, if you make [u]divdi3 work for SDI (i.e. also for -m32) we'll never
> have to special-case it again (also [u]moddi3?)
Maybe, but there are no explicit calls to those, so I left them
as is, since if we touch those, then we probably need to look at
almost all logical/arithmetic patterns...and that is a lot of work
not needed to fix this specific issue.
> Yes, if you make [u]divdi3 work for SDI (i.e. also for -m32) we'll never
> have to special-case it again (also [u]moddi3?)
Heh, looking at "mod<mode>3", I see it calls gen_div<mode>3(), but since
there are no explicit calls to gen_moddi3(), we don't really have a problem.
> But this then also will be used by expand, when generation a DImode
> divide. Does it generate code at least as good as what the generic code
> generates? It probably will, but check please.
The change from GPR to SDI iterator and my change to explicitly call
the __divdi3() lib function for DImode divides ends up generating the
exact same code generated for the following test case that we get with
the non patched compiler:
long long
foo (long long a, long long b)
{
return a / b;
}
Peter
