The ARCompact architecture has some pipelining features that result in
the vanilla branch shortening not always converging.
Moreover, there are some short, complex branch instructions with very short
offsets; replacing them with a multi-insn sequence when the offset doesn't
reach makes the code s
Quoting Richard Guenther :
I miss a few things in this description:
- what is the value of lock_length supposed to be? From the "lock"
prefix it sounds like it is something unchanging, maybe even constant,
thus a maximum?
- the length attribute still needs to be specified when lock_length i
2012-10-04 Joern Rennecke
* final.c (get_attr_length_1): Use direct recursion rather than
calling get_attr_length.
(get_attr_lock_length): New function.
(INSN_VARIABLE_LENGTH_P): Define.
(shorten_branches): Take HAVE_ATTR_lock_length into account.
On Wed, Oct 3, 2012 at 8:22 PM, Joern Rennecke
wrote:
> The ARCompact architecture has some pipelining features that result in
> the vanilla branch shortening not always converging.
>
> Moreover, there are some short, complex branch instructions with very short
> offsets; replacing them with a mul
Joern Rennecke writes:
> 2012-10-04 Joern Rennecke
>
> * final.c (get_attr_length_1): Use direct recursion rather than
> calling get_attr_length.
> (get_attr_lock_length): New function.
> (INSN_VARIABLE_LENGTH_P): Define.
> (shorten_branches): Take H
Quoting Richard Sandiford :
Joern Rennecke writes:
2012-10-04 Joern Rennecke
* final.c (get_attr_length_1): Use direct recursion rather than
calling get_attr_length.
(get_attr_lock_length): New function.
(INSN_VARIABLE_LENGTH_P): Define.
(shorte
On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
wrote:
> Quoting Richard Sandiford :
>
>> Joern Rennecke writes:
>>>
>>> 2012-10-04 Joern Rennecke
>>>
>>> * final.c (get_attr_length_1): Use direct recursion rather than
>>> calling get_attr_length.
>>> (get_attr_lock_
Joern Rennecke writes:
> @@ -1360,12 +1369,20 @@ shorten_branches (rtx first ATTRIBUTE_UN
> else
> inner_length = insn_current_length (inner_insn);
>
> - if (inner_length != insn_lengths[inner_uid])
> + /* We can't record lengths of d
Quoting Richard Sandiford :
The fact that we even have shared unique ids is pretty bad -- and surely
a contradiction in terms -- but I think both ways of handling them rely
on the length being the same for all copies. If we don't record a length
(your version), we won't set something_changed if
Joern Rennecke writes:
> Quoting Richard Sandiford :
>> The fact that we even have shared unique ids is pretty bad -- and surely
>> a contradiction in terms -- but I think both ways of handling them rely
>> on the length being the same for all copies. If we don't record a length
>> (your version)
Quoting Richard Sandiford :
Joern Rennecke writes:
When the condition is not fulfilled, we want to keep the length from the
previous iteration.
Right, that's what I mean. So we need to make sure that the difference
between the address of the current instruction and the address of the
next
Joern Rennecke writes:
> @@ -1165,6 +1175,7 @@ shorten_branches (rtx first ATTRIBUTE_UN
> get the current insn length. If it has changed, reflect the change.
> When nothing changes for a full pass, we are done. */
>
> + bool first_pass ATTRIBUTE_UNUSED = true;
>while (somethin
Quoting Richard Sandiford :
I think instead the set-up loop should have:
if (GET_CODE (body) == ADDR_VEC || GET_CODE (body) == ADDR_DIFF_VEC)
{
#ifdef CASE_VECTOR_SHORTEN_MODE
if (increasing && GET_CODE (body) == ADDR_DIFF_VEC)
PUT_MODE (body, CASE_VECTOR_SHO
Joern Rennecke writes:
> Quoting Richard Sandiford :
>> I think instead the set-up loop should have:
>>
>> if (GET_CODE (body) == ADDR_VEC || GET_CODE (body) == ADDR_DIFF_VEC)
>> {
>> #ifdef CASE_VECTOR_SHORTEN_MODE
>>if (increasing && GET_CODE (body) == ADDR_DIFF_VEC)
>>
Quoting Richard Biener :
On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
wrote:
..
Well, we could split it anyway, and give ports without the need for
multiple length attributes the benefit of the optimistic algorithm.
I have attached a patch that implements this.
Looks reasonable to me, t
On Wed, Oct 24, 2012 at 3:42 AM, Joern Rennecke
wrote:
> Quoting Richard Biener :
>
>> On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
>> wrote:
>
> ..
>>>
>>> Well, we could split it anyway, and give ports without the need for
>>> multiple length attributes the benefit of the optimistic algorith
Quoting Richard Biener :
Just to add some extra information, can you quote your ports
ADJUST_INSN_LENGTH and one example instruction with length/lock_length
attribute the above applies to?
This is a bit besides the point, since lock_length does mostly the traditional
branch shortening (with al
On Tue, 23 Oct 2012, Joern Rennecke wrote:
> I'll be posting the ARC port shortly; it does not fit into a single 100 KB
> posting, so I'm thinking of splitting it in a configury patch and zx
> compressed files/tarballs for arc.c, arc.md, libgcc, and the rest of the port.
The size limit is 400 kB,
18 matches
Mail list logo
