On 13/5/15 9:43 PM, Kugan wrote:
> On 14/05/13 19:18, Ramana Radhakrishnan wrote:
>> On 05/13/13 04:15, Kugan wrote:
>>> Hi,
>>>
>>> Ping this patch by Chung-Lin.
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
>>>
>>> This patch allows lr registers to be used in leaf functions for ARM.
On 14/05/13 19:18, Ramana Radhakrishnan wrote:
On 05/13/13 04:15, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression i
On 14/05/13 00:24, Chung-Lin Tang wrote:
On 13/5/13 11:15 AM, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in th
On 05/13/13 04:15, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in thumb2 mode for
CoreMark. However, looking at
On 13/5/13 11:15 AM, Kugan wrote:
> Hi,
>
> Ping this patch by Chung-Lin.
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
>
> This patch allows lr registers to be used in leaf functions for ARM.
>
> There were some concerns about performance regression in thumb2 mode for
> CoreMark. Ho
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in thumb2 mode for
CoreMark. However, looking at the code further shows that this
Ping.
On 2011/5/26 01:29 AM, Chung-Lin Tang wrote:
> On 2011/5/20 07:46 PM, Chung-Lin Tang wrote:
>> On 2011/5/20 下午 07:41, Ramana Radhakrishnan wrote:
>>> On 17/05/11 14:10, Chung-Lin Tang wrote:
On 2011/5/13 04:26 PM, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Chung-Lin
On 2011/5/20 07:46 PM, Chung-Lin Tang wrote:
> On 2011/5/20 下午 07:41, Ramana Radhakrishnan wrote:
>> On 17/05/11 14:10, Chung-Lin Tang wrote:
>>> On 2011/5/13 04:26 PM, Richard Sandiford wrote:
Richard Sandiford writes:
> Chung-Lin Tang writes:
>> My fix here simply adds 'reload_comp
On 2011/5/20 下午 07:41, Ramana Radhakrishnan wrote:
> On 17/05/11 14:10, Chung-Lin Tang wrote:
>> On 2011/5/13 04:26 PM, Richard Sandiford wrote:
>>> Richard Sandiford writes:
Chung-Lin Tang writes:
> My fix here simply adds 'reload_completed' as an additional condition
> for EPILOGUE
On 17/05/11 14:10, Chung-Lin Tang wrote:
On 2011/5/13 04:26 PM, Richard Sandiford wrote:
Richard Sandiford writes:
Chung-Lin Tang writes:
My fix here simply adds 'reload_completed' as an additional condition
for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
valid, as cor
> > It seems a lot of other ports suffer from the same problem though.
> > I wonder which targets really do want to make a register live throughout
> > the function? If none do, perhaps we should say that this macro is
> > only meaningful once the epilogue has been generated.
>
> To answer my own
On 2011/5/13 04:26 PM, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Chung-Lin Tang writes:
>>> My fix here simply adds 'reload_completed' as an additional condition
>>> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
>>> valid, as correct LR save/restoring is han
Richard Sandiford writes:
> Chung-Lin Tang writes:
>> My fix here simply adds 'reload_completed' as an additional condition
>> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
>> valid, as correct LR save/restoring is handled by the epilogue/prologue
>> code; it should be sa
Chung-Lin Tang writes:
> My fix here simply adds 'reload_completed' as an additional condition
> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
> valid, as correct LR save/restoring is handled by the epilogue/prologue
> code; it should be safe for IRA to treat it as a norma
Hi, this patch tries to solve the problem of the LR register not
being used in leaf functions on ARM.
Looking at the dumps, it shows that register 14 (lr) conflicts with all
allocnos throughout the entire leaf procedure. A little digging shows
that lr is present in the OBJECT_CONFLICT_HARD_REGS()
15 matches
Mail list logo
