Sorry to be coming back to this problem, I'm working on many projects
at the same time at the moment.
The port actually has a shift-immediate. It actually sees it later in
the fwprop pass:
In insn 14, replacing
(ashift:DI (reg:DI 79)
(reg:DI 77))
with (ashift:DI (reg:DI 79)
(con
Jean Christophe Beyler wrote:
I've gone back to this problem (since I've solved another one ;-)).
And I've moved forward a bit:
It seems that if I consider an array of characters, there are no
longer any shifts and therefore I do get my two loads with the use of
an offset:
The reason there are
I've gone back to this problem (since I've solved another one ;-)).
And I've moved forward a bit:
It seems that if I consider an array of characters, there are no
longer any shifts and therefore I do get my two loads with the use of
an offset:
Code:
char data[1312];
uint64_t goo (uint64_t i)
{
Ok, for the i386 port, I use uint32_t instead of uint64_t because
otherwise the assembly code generated is a bit complicated (I'm on a
32 bit machine).
The tree dump from final_cleanup are the same for the goo function:
goo (i)
{
:
return data[i + 13] + data[i];
}
However, the first RTL dump
> It seems that when set in a loop, the program is able to perform some
> type of optimization to actually get the use of the offsets where as
> in the case of no loop, we have twice the calculations of instructions
> for each address calculations.
I suggest you look at the dumps for i386 to see
Dear all,
I come back to you with another weirdness due to bad code generation
on my target architecture. I have a very simplified (for the moment)
rtx_costs and my address_cost is inspired by the i386 version.
However, I actually patched in the whole i386_rtx_cost function,
constraints, predicate
