Jakub Jelinek wrote:
Richard Sandiford wrote:
OK, how about this? It looks like the builtins.c and stmt.c stuff wasn't
merged until 4.9, and at this stage it seemed safer to just add the same
use/clobber sequence to both places.
Please wait a little bit, the patch has been committed to the tr
On Thu, Mar 13, 2014 at 07:15:34AM +, Richard Sandiford wrote:
> Eric Botcazou writes:
> >> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
> >
> > Thanks. We need something for the 4.8 branch as well, probably the
> > builtins.c
> > hunk and the reversion of the
Eric Botcazou writes:
>> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
>
> Thanks. We need something for the 4.8 branch as well, probably the
> builtins.c
> hunk and the reversion of the cse.c/cselib.c/dse.c changes to the 4.7 state.
OK, how about this? It looks
> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
Thanks. We need something for the 4.8 branch as well, probably the builtins.c
hunk and the reversion of the cse.c/cselib.c/dse.c changes to the 4.7 state.
--
Eric Botcazou
Hans-Peter Nilsson writes:
> On Mon, 3 Mar 2014, Richard Sandiford wrote:
>> AIUI:
>
> Reading back the references don't yield any dissenting
> flash-backs, FWIW.
>
> So, a (use fp) then a (clobber fp)? That was probably just too
> weird for me to think of, much like a hypercorrect ending of the
On Mon, 3 Mar 2014, Richard Sandiford wrote:
> AIUI:
Reading back the references don't yield any dissenting
flash-backs, FWIW.
So, a (use fp) then a (clobber fp)? That was probably just too
weird for me to think of, much like a hypercorrect ending of the
previous clause. :)
Thanks for dealing w
Richard wrote:
> The thread seems to have died down,
> so should I go ahead and install it?
Looks like all reviews were more or less positive...
-Y
Bernd Schmidt writes:
> On 03/03/2014 11:01 PM, Richard Sandiford wrote:
>
>> I'll run a full test overnight, but does this look like it might be
>> a way out, at least for 4.9?
>
> Pretty much agree with everything you've written in this thread. I
> think this patch is fine.
Thanks. The threa
On 03/03/2014 11:01 PM, Richard Sandiford wrote:
I'll run a full test overnight, but does this look like it might be
a way out, at least for 4.9?
Pretty much agree with everything you've written in this thread. I
think this patch is fine.
gcc/
* builtins.c (expand_builtin_setjmp_r
Richard Biener writes:
> On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
> wrote:
>> AIUI:
>>
>> (1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
>> was that we had:
>>
>> emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
>> /* This m
On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
wrote:
> AIUI:
>
> (1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
> was that we had:
>
> emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
> /* This might change the hard frame pointer
Eric Botcazou writes:
>> That doesn't really answer the question though. What's the correct
>> behaviour for an unspec volatile in a loop? I don't think it's what
>> we did in the example above, since it doesn't seem self-consistent.
>> And "not spending too much time" is again a bit vague in te
Richard Sandiford writes:
> I'll run a full test overnight, but does this look like it might be
> a way out, at least for 4.9?
FWIW, it passed testing on x86_64-linux-gnu ({,-m32}, all,ada).
Here it is again with an updated cselib.c comment. OK to install?
Thanks,
Richard
gcc/
* built
> That doesn't really answer the question though. What's the correct
> behaviour for an unspec volatile in a loop? I don't think it's what
> we did in the example above, since it doesn't seem self-consistent.
> And "not spending too much time" is again a bit vague in terms of
> saying what's righ
AIUI:
(1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
was that we had:
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
/* This might change the hard frame pointer in ways that aren't
apparent to early optimization passes, so
On Mar 1, 2014, at 6:36 AM, Eric Botcazou wrote:
> It introduces a new, temporary predicate really_volatile_insn_p
really is a really horrible name. Hint, if cs domain specific wikipedia
describe what you were doing, what would the page be called? really is
unlikely to be it.
Eric Botcazou writes:
>>> ...it's so loosely defined. If non-local labels are the specific problem,
>> I think it'd be better to limit the flush to that.
>
> No, there was "e.g." written so non-local labels are not the only problem.
What are the others though? As discussed in the other subthrea
> ...it's so loosely defined. If non-local labels are the specific problem,
> I think it'd be better to limit the flush to that.
No, there was "e.g." written so non-local labels are not the only problem.
> I'm back to throwing examples around, sorry, but take the MIPS testcase:
>
> volatile
Eric Botcazou writes:
>> non-local labels should block most optimizations by the fact they
>> are a receiver of control flow and thus should have an abnormal
>> edge coming into them. If that's not the case (no abnormal edge)
>> then that's the bug to fix.
>
> It's (of course) more complicated, y
> non-local labels should block most optimizations by the fact they
> are a receiver of control flow and thus should have an abnormal
> edge coming into them. If that's not the case (no abnormal edge)
> then that's the bug to fix.
It's (of course) more complicated, you need to look at HP's fix an
On Mon, Mar 3, 2014 at 9:01 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
>>> But the implication seems to be that unspec_volatile and volatile asms
>>> are volatile in different ways. IMO they're volatile in th
Eric Botcazou writes:
>> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
>> But the implication seems to be that unspec_volatile and volatile asms
>> are volatile in different ways. IMO they're volatile in the same way
>> and the problems for volatile asms apply to unspe
> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix.
> But the implication seems to be that unspec_volatile and volatile asms
> are volatile in different ways. IMO they're volatile in the same way
> and the problems for volatile asms apply to unspec_volatile too.
I disagree
Eric Botcazou writes:
> There seems to be a sufficiently large consensus that volatile asms should
> not
> be treated as full optimization barriers by the compiler. This patch is a
> first step towards implementing this conclusion and aims only at addressing
> the code quality regressions int
There seems to be a sufficiently large consensus that volatile asms should not
be treated as full optimization barriers by the compiler. This patch is a
first step towards implementing this conclusion and aims only at addressing
the code quality regressions introduced by
http://gcc.gnu.org/vi
25 matches
Mail list logo
