On 08/12/10 14:39, Jeff Law wrote:
>> Sorry, I think I wasn't clear. I didn't mean constraints in term on
>> RTL template constraints, but 'constraints' coming from the new DI
>> destination of the load. More specifically: 2 SI loads can target
>> totally independent registers whereas a standard D
On 8 December 2010 17:37, Jeff Law wrote:
> On 12/08/10 09:18, Frederic Riss wrote:
>>
>> OK, I see your point, but I tend to think the the odds of the register
>> allocator being able to coalesce the additional DI->SI moves in the
>> pre-IRA approach are by far higher that the odds of having merg
On 12/08/10 09:43, Paul Koning wrote:
On Dec 8, 2010, at 11:37 AM, Jeff Law wrote:
On 12/08/10 09:18, Frederic Riss wrote:
OK, I see your point, but I tend to think the the odds of the register
allocator being able to coalesce the additional DI->SI moves in the
pre-IRA approach are by far high
Paul Koning writes:
> This probably has been discussed at length in the past, but as a
> relative newcomer I'll make this observation... I wonder how much is
> lost by GCC's insistence that multi-register values must be in
> adjacent registers. Obviously that's hard to change (the registers
> w
On Dec 8, 2010, at 11:37 AM, Jeff Law wrote:
> On 12/08/10 09:18, Frederic Riss wrote:
>>
>> OK, I see your point, but I tend to think the the odds of the register
>> allocator being able to coalesce the additional DI->SI moves in the
>> pre-IRA approach are by far higher that the odds of having
On 12/08/10 09:18, Frederic Riss wrote:
OK, I see your point, but I tend to think the the odds of the register
allocator being able to coalesce the additional DI->SI moves in the
pre-IRA approach are by far higher that the odds of having merge
candidates after register allocation.
I agree, but
On 8 December 2010 15:39, Jeff Law wrote:
> On 12/08/10 01:40, Frederic Riss wrote:
>> Sorry, I think I wasn't clear. I didn't mean constraints in term on
>> RTL template constraints, but 'constraints' coming from the new DI
>> destination of the load. More specifically: 2 SI loads can target
>> t
On 12/08/10 01:40, Frederic Riss wrote:
On 8 December 2010 00:12, Jeff Law wrote:
On 12/07/10 12:29, Frédéric RISS wrote:
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
On 12/06/10 15:07, Ian Lance Taylor wrote:
Given the two loads don't have a def-use data dependency combine won
On 8 December 2010 00:12, Jeff Law wrote:
> On 12/07/10 12:29, Frédéric RISS wrote:
>>
>> Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
>>>
>>> On 12/06/10 15:07, Ian Lance Taylor wrote:
>>> Given the two loads don't have a def-use data dependency combine won't
>>> ever get the oppor
On 12/07/10 12:29, Frédéric RISS wrote:
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
On 12/06/10 15:07, Ian Lance Taylor wrote:
Given the two loads don't have a def-use data dependency combine won't
ever get the opportunity to do anything with them. In general there is
no pass wh
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
> On 12/06/10 15:07, Ian Lance Taylor wrote:
> Given the two loads don't have a def-use data dependency combine won't
> ever get the opportunity to do anything with them. In general there is
> no pass which combines insns without a true
On 12/06/10 15:07, Ian Lance Taylor wrote:
roy rosen writes:
If I have two load SI insns. Is there any way to combine them into one
load DI insn?
Not using peephole which can catch only this limited case of being
sequential insns.
I have seen something done in ARM (*arith_adjacentmem) but it i
roy rosen writes:
> If I have two load SI insns. Is there any way to combine them into one
> load DI insn?
> Not using peephole which can catch only this limited case of being
> sequential insns.
> I have seen something done in ARM (*arith_adjacentmem) but it is very
> awkward and would not be re
13 matches
Mail list logo
