On 12-10-15 8:06 AM, Richard Sandiford wrote:
Vladimir Makarov writes:
if that's accurate. I dropped the term "reload pseudo" because of
the general comment in my earlier reply about the use of "reload pseudo"
when the code seems to include inheritance and split pseudos too.
There is no inher
On 12-10-17 7:24 AM, Richard Sandiford wrote:
Thanks for all the updates.
Vladimir Makarov writes:
+ /* index * scale + disp => new base + index * scale */
+ enum reg_class cl = base_reg_class (mode, as, SCRATCH, SCRATCH);
+
+ lra_assert (INDEX_REG_CLASS != NO_REGS);
+
On Wed, Oct 17, 2012 at 9:53 PM, Vladimir Makarov wrote:
> On 12-10-15 12:49 PM, Richard Sandiford wrote:
>> Getting rid of reload always seemed like a pipe dream, and if the only
>> known drawback of this replacement is that it takes a while on extreme
>> testcases, that's an amazing achievement.
On 12-10-15 12:49 PM, Richard Sandiford wrote:
Hi Vlad,
Some comments about the rest of LRA. Nothing major here...
Vladimir Makarov writes:
+/* Info about register in an insn. */
+struct lra_insn_reg
+{
+ /* The biggest mode through which the insn refers to the register
+ (remember the
Thanks for all the updates.
Vladimir Makarov writes:
>>> + /* index * scale + disp => new base + index * scale */
>>> + enum reg_class cl = base_reg_class (mode, as, SCRATCH, SCRATCH);
>>> +
>>> + lra_assert (INDEX_REG_CLASS != NO_REGS);
>>> + new_reg = lra_create_new_reg (Pmode,
On 12-10-12 10:29 AM, Richard Sandiford wrote:
Hi Vlad,
Comments for the rest of ira-constraints.c.
Vladimir Makarov writes:
+ saved_base_reg = saved_base_reg2 = saved_index_reg = NULL_RTX;
+ change_p = equiv_address_substitution (&ad, addr_loc, mode, as, code);
+ if (ad.base_reg_loc != NU
Hi Vlad,
Some comments about the rest of LRA. Nothing major here...
Vladimir Makarov writes:
> +/* Info about register in an insn. */
> +struct lra_insn_reg
> +{
> + /* The biggest mode through which the insn refers to the register
> + (remember the register can be accessed through a subr
Vladimir Makarov writes:
>> if that's accurate. I dropped the term "reload pseudo" because of
>> the general comment in my earlier reply about the use of "reload pseudo"
>> when the code seems to include inheritance and split pseudos too.
> There is no inheritance and splitting yet. It is done a
I'm having to correct my own comments again, sorry.
Richard Sandiford writes:
>> + /* If this is post-increment, first copy the location to the reload reg.
>> */
>> + if (post && real_in != result)
>> +emit_insn (gen_move_insn (result, real_in));
>
> Nit, but real_in != result can never b
Vladimir Makarov writes:
>>> +/* Info about pseudo used during the assignment pass. Thread is a set
>>> + of connected reload and inheritance pseudos with the same set of
>>> + available hard reg set. Thread is a pseudo itself for other
>>> + cases. */
>>> +struct regno_assign_info
>> May
Hi Vlad,
Comments for the rest of ira-constraints.c.
Vladimir Makarov writes:
> + saved_base_reg = saved_base_reg2 = saved_index_reg = NULL_RTX;
> + change_p = equiv_address_substitution (&ad, addr_loc, mode, as, code);
> + if (ad.base_reg_loc != NULL)
> +{
> + if (process_addr_reg
>
On 10/04/2012 11:50 AM, Richard Sandiford wrote:
Hi Vlad,
This message is for lra-assigns.c. Sorry for the piecemeal reviews,
never sure when I'll get time...
+/* This file contains a pass mostly assigning hard registers to reload
+ pseudos. There is no any RTL code transformation on this
On 12-10-03 7:11 AM, Richard Sandiford wrote:
Hi Vlad,
Some comments on lra-spills.c and lra-coalesce.c.
+ The pass creates necessary stack slots and assign spilled pseudos
+ to the stack slots in following way:
s/assign/assigns/
Fixed.
+ (or insn memory constraints) might be not sati
Sorry, reading back in different surroundings made me notice a couple
of silly errors:
Richard Sandiford writes:
> E.g.:
>
> if ((*loc = get_equiv_substitution (reg)) != reg)
> ...as above...
> if (*loc != reg || !in_class_p (reg, cl, &new_class))
> ...as above...
> else if (new_cla
On 12-10-02 10:14 AM, Richard Sandiford wrote:
Richard Sandiford writes:
+/* Merge ranges R1 and R2 and returns the result. The function
+ maintains the order of ranges and tries to minimize size of the
+ result range list. */
+lra_live_range_t
+lra_merge_live_ranges (lra_live_range_t r1,
On 12-10-02 9:42 AM, Richard Sandiford wrote:
Vladimir Makarov writes:
This is the major patch containing all new files. The patch also adds
necessary calls to LRA from IRA.As the patch is too big, it continues in
the next email.
2012-09-27 Vladimir Makarov
* Makefile.in (LRA_INT_H)
On 10/09/2012 06:17 AM, Richard Sandiford wrote:
Thanks for the updates.
Vladimir Makarov writes:
+ a change in the offset between the eliminable register and its
+ substitution if UPDATE_P, or the full offset if FULL_P, or
+ otherwise zero.
I wonder if an enum would be better than two
Thanks for the updates.
Vladimir Makarov writes:
>>> + a change in the offset between the eliminable register and its
>>> + substitution if UPDATE_P, or the full offset if FULL_P, or
>>> + otherwise zero.
>> I wonder if an enum would be better than two booleans?
>> It avoids invalid combina
On 12-10-02 7:21 AM, Richard Sandiford wrote:
Hi Vlad,
Vladimir Makarov writes:
+LRA is different from the reload pass in LRA division on small,
+manageable, and separated sub-tasks. All LRA transformations and
+decisions are reflected in RTL as more as possible. Instruction
+constraints as
On 12-10-05 5:53 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 2:59 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
wrote:
Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
opera
On Thu, Oct 4, 2012 at 2:59 PM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
> wrote:
>> Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
>
> Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
> operates in cfgrtl mode, so the sequence
On Thu, Oct 4, 2012 at 5:31 PM, Vladimir Makarov wrote:
>
> Wow. I did not have such effect. What machine do you use?
I do all my testing on gcc17.
Ciao!
Steven
On 10/04/2012 02:57 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
I was going to look at this code too but I was interesting in generation of
less points and live ranges. It is strange that in my profiles,
remove_some_program_points_and_update_live_ranges t
Hi Vlad,
This message is for lra-assigns.c. Sorry for the piecemeal reviews,
never sure when I'll get time...
> +/* This file contains a pass mostly assigning hard registers to reload
> + pseudos. There is no any RTL code transformation on this pass.
Maybe:
/* This file's main objective is
On 10/04/2012 05:43 AM, Steven Bosscher wrote:
On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
The "worst" result is this:
Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
post_count 12483414
But that's still a lot better than before the patch for the same functi
On 10/04/2012 03:24 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 8:57 AM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
I was going to look at this code too but I was interesting in generation of
less points and live ranges. It is strange that in my prof
On Thu, Oct 4, 2012 at 1:30 PM, Richard Guenther
wrote:
> Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order?
Not at this stage. For cfglayout mode I would answer yes, but IRA/LRA
operates in cfgrtl mode, so the sequence of insns and basic blocks
must match. Therefore, if you walk the b
On Thu, Oct 4, 2012 at 11:43 AM, Steven Bosscher wrote:
> On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
>> The "worst" result is this:
>> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
>> post_count 12483414
>>
>> But that's still a lot better than before the pa
On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
> The "worst" result is this:
> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
> post_count 12483414
>
> But that's still a lot better than before the patch for the same function:
> Compressing live ranges: from 17425
On Thu, Oct 4, 2012 at 8:57 AM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
>> I was going to look at this code too but I was interesting in generation of
>> less points and live ranges. It is strange that in my profiles,
>> remove_some_program_points_and_upd
On Thu, Oct 4, 2012 at 5:30 AM, Vladimir Makarov wrote:
> I was going to look at this code too but I was interesting in generation of
> less points and live ranges. It is strange that in my profiles,
> remove_some_program_points_and_update_live_ranges takes 0.6% of compiler
> time on these huge t
On 12-10-03 11:35 AM, Steven Bosscher wrote:
On Wed, Oct 3, 2012 at 4:56 PM, Vladimir Makarov wrote:
On 12-10-03 3:13 AM, Steven Bosscher wrote:
On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
+/* Compress pseudo live ranges by removing program points where
+ nothing happens. Com
On Wed, Oct 3, 2012 at 4:56 PM, Vladimir Makarov wrote:
> On 12-10-03 3:13 AM, Steven Bosscher wrote:
>>
>> On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
>> wrote:
+/* Compress pseudo live ranges by removing program points where
+ nothing happens. Complexity of many algorith
On 12-10-03 3:13 AM, Steven Bosscher wrote:
On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
+/* Compress pseudo live ranges by removing program points where
+ nothing happens. Complexity of many algorithms in LRA is linear
+ function of program points number. To speed up the code
Hi Vlad,
Some comments on lra-spills.c and lra-coalesce.c.
> + The pass creates necessary stack slots and assign spilled pseudos
> + to the stack slots in following way:
s/assign/assigns/
> + (or insn memory constraints) might be not satisfied any more.
s/might be not/might not be/
> +
On Tue, Oct 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
>
>> +/* Compress pseudo live ranges by removing program points where
>> + nothing happens. Complexity of many algorithms in LRA is linear
>> + function of program points number. To speed up the code we try to
>> + minimize the numbe
On 10/02/2012 06:42 PM, Bernd Schmidt wrote:
On 10/03/2012 12:29 AM, Vladimir Makarov wrote:
On 12-10-02 7:30 AM, Bernd Schmidt wrote:
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
+ We keep RTL code at most time in such state that the virtual
+ registers can be changed by just the corre
On 10/03/2012 12:29 AM, Vladimir Makarov wrote:
> On 12-10-02 7:30 AM, Bernd Schmidt wrote:
>> On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
>>> + We keep RTL code at most time in such state that the virtual
>>> + registers can be changed by just the corresponding hard registers
>>> + (with
On 12-10-02 7:30 AM, Bernd Schmidt wrote:
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
+ We keep RTL code at most time in such state that the virtual
+ registers can be changed by just the corresponding hard registers
+ (with zero offsets) and we have the right RTL code. To achieve this
Richard Sandiford writes:
>> +/* Merge ranges R1 and R2 and returns the result. The function
>> + maintains the order of ranges and tries to minimize size of the
>> + result range list. */
>> +lra_live_range_t
>> +lra_merge_live_ranges (lra_live_range_t r1, lra_live_range_t r2)
>> +{
>> +
Vladimir Makarov writes:
> This is the major patch containing all new files. The patch also adds
> necessary calls to LRA from IRA.As the patch is too big, it continues in
> the next email.
>
> 2012-09-27 Vladimir Makarov
>
> * Makefile.in (LRA_INT_H): New.
> (OBJS): Add lra.o, lra
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
> + We keep RTL code at most time in such state that the virtual
> + registers can be changed by just the corresponding hard registers
> + (with zero offsets) and we have the right RTL code. To achieve this
> + we should add initial offs
Hi Vlad,
Vladimir Makarov writes:
> This is the major patch containing all new files. The patch also adds
> necessary calls to LRA from IRA.As the patch is too big, it continues in
> the next email.
>
> 2012-09-27 Vladimir Makarov
>
> * Makefile.in (LRA_INT_H): New.
> (OBJS): Add
43 matches
Mail list logo
