On Fri, Nov 4, 2011 at 9:07 AM, Alan Modra wrote:
> OK to apply? gcc-4.6 branch too?
>
> PR target/50906
> * config/rs6000/rs6000.c (rs6000_emit_prologue ):
> Do not mark r11 setup as frame-related. Pass correct offset to
> rs6000_emit_savres_rtx. Correct out-of-lin
Ping http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00543.html
--
Alan Modra
Australia Development Lab, IBM
On Nov 17, 2011, at 20:46 , David Edelsohn wrote:
> Coincidentally, IBM's XL compiler is encountering a similar issue and
> proposing a similar solution of having the stack pointer update
> conflict with all memory accesses.
Interesting timing :-)
> I think all these corner cases
> confirm tha
Coincidentally, IBM's XL compiler is encountering a similar issue and
proposing a similar solution of having the stack pointer update
conflict with all memory accesses. I think all these corner cases
confirm that it is impractical for the compiler to track all accesses
against SP and the only expe
On Wed, Nov 16, 2011 at 6:54 AM, Olivier Hainque wrote:
>
> On Nov 9, 2011, at 18:15 , Olivier Hainque wrote:
>> I'm not convinced that the potential gain is worth the extra
>> complexity and potential risk of running into another subtle
>> subcase, with hard to track sporadic runtime failures for
On Nov 9, 2011, at 18:15 , Olivier Hainque wrote:
> I'm not convinced that the potential gain is worth the extra
> complexity and potential risk of running into another subtle
> subcase, with hard to track sporadic runtime failures for
> starters. I don't have numbers though.
>
> That's a port ma
On Nov 8, 2011, at 2:40 PM, Alan Modra wrote:
> On Tue, Nov 08, 2011 at 11:37:57AM +0100, Olivier Hainque wrote:
>> Joseph resorted to mem:scratch to impose a strong barrier. That's certainly
>> safe and I don't think the performance impact can be significant, so this
>> looks like a good way out
On Tue, Nov 08, 2011 at 11:37:57AM +0100, Olivier Hainque wrote:
> Joseph resorted to mem:scratch to impose a strong barrier. That's certainly
> safe and I don't think the performance impact can be significant, so this
> looks like a good way out.
I agree. Our fancy powerpc stack deallocation
On Nov 8, 2011, at 6:13 AM, Alan Modra wrote:
> It's been a while since I looked at what was happening with this
> testcase, but from memory what stops sheduling over the stack_tie is
> alias.c:base_alias_check. Which relies on tracking registers to see
> whether two memory accesses using differ
On Tue, Nov 08, 2011 at 12:30:36AM +, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Alan Modra wrote:
>
> > OK, so you made the stack ties conflict with all memory. I wondered
> > about that too, but didn't find a testcase where it mattered. It
>
> The test I had was one of those from the va
On Tue, 8 Nov 2011, Alan Modra wrote:
> OK, so you made the stack ties conflict with all memory. I wondered
> about that too, but didn't find a testcase where it mattered. It
The test I had was one of those from the various PRs for this issue.
int find_num(int i)
{
const int arr[5] = {0, 1,
On Mon, Nov 07, 2011 at 04:10:38PM +, Joseph S. Myers wrote:
> FWIW, when I encountered such a problem in 4.4-based tools I found I
> needed the following change to stack_tie patterns to fix it (applied to
> and rediffed against trunk, but not tested there), in addition to a
> DEFAULT_ABI ==
On Mon, 7 Nov 2011, Alan Modra wrote:
> On Mon, Nov 07, 2011 at 10:53:51AM +0100, Olivier Hainque wrote:
> > Another bug we're running into here is an unwarranted move of the sp
> > restore prior to register fetches despite an attempt at preventing that
> > with a stack_tie instruction (VxWorks ta
On Mon, Nov 7, 2011 at 4:53 AM, Olivier Hainque wrote:
> There are lots of subtle inter-section dependencies and redundancies
> in emit_epilogue, which has grown pretty difficult to understand IMHO.
>
> I can see two tracks to improve things in this area:
>
> - Concentrate on the sp-move problem
On Nov 7, 2011, at 12:02 PM, Alan Modra wrote:
>> The failure can still be exposed on mainline with a minor adjustment
>> to the C testcase quoted in the msg.
>
> Even after revision 181056?
I'll double check but I'm pretty sure that this change cannot
help the specific problem at hand. VxWor
On Mon, Nov 07, 2011 at 10:53:51AM +0100, Olivier Hainque wrote:
> Another bug we're running into here is an unwarranted move of the sp
> restore prior to register fetches despite an attempt at preventing that
> with a stack_tie instruction (VxWorks target).
>
> http://gcc.gnu.org/ml/gcc/2011-03
On 7 Nov 2011, at 09:53, Olivier Hainque wrote:
On Nov 4, 2011, at 2:07 PM, Alan Modra wrote:
Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some
also
for other ABIs.
...
Another bug we're running into here is an unwarranted move of the sp
restore prior to register fetches
On Nov 4, 2011, at 2:07 PM, Alan Modra wrote:
> Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some also
> for other ABIs.
...
Another bug we're running into here is an unwarranted move of the sp
restore prior to register fetches despite an attempt at preventing that
with a stack_t
On Fri, Nov 04, 2011 at 06:19:07PM +, Iain Sandoe wrote:
> I did wonder, when implementing the out-of-line saves for Darwin,
> whether the setting in sysv4.h is a bit optimistic in firing for r31
> when -Os is on.
>
> whether it saves space, in reality, would presumably depend on
> whether bra
Hello Alan,
On 4 Nov 2011, at 13:07, Alan Modra wrote:
Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some also
for other ABIs.
1) Marking an instruction setting up r11 for use by _save64gpr_* as
frame-related results in r11 being set as the cfa for the rest of the
function. Tha
Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some also
for other ABIs.
1) Marking an instruction setting up r11 for use by _save64gpr_* as
frame-related results in r11 being set as the cfa for the rest of the
function. That's bad when r11 gets used for other things later.
Even wor
21 matches
Mail list logo
