> I was mainly arguing with the sentence that for asm volatile, the output
> constraints (did you mean outputs and clobbers?) have essentially no
> meaning. While for some optimizations perhaps it might be desirable
> to treat asm volatile as full optimization barrier, I'm not sure about all
> of
On 11/27/2012 04:03 AM, Jakub Jelinek wrote:
> 2012-11-26 Jakub Jelinek
>
> PR debug/36728
> PR debug/55467
> * cselib.c (cselib_process_insn): If cselib_preserve_constants,
> don't reset table and exit early on volatile insns and setjmp.
> Reset table afterwards o
On 11/27/2012 09:35 AM, Eric Botcazou wrote:
> It's well established in the RTL middle-end that UNSPEC_VOLATILE can do
> pretty
> much everything behind the back of the compiler.
This is false. U_V is a scheduling barrier, and is never deleted as
dead (as opposed to unreachable) code. Certainl
Eric Botcazou writes:
>> I strongly disagree with this. Outputs and clobbers have significant
>> meaning even on volatile asms, asm volatile doesn't mean all registers and
>> all memory are supposed to be considered clobbered. For memory you have
>> "memory" clobber for that, for registers it is
On Wed, Nov 28, 2012 at 08:44:18AM -0500, Hans-Peter Nilsson wrote:
> On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> > 2012-11-26 Jakub Jelinek
> >
> > PR debug/36728
> > PR debug/55467
> > * cselib.c (cselib_process_insn): If cselib_preserve_constants,
> > don't reset table and exi
On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> 2012-11-26 Jakub Jelinek
>
> PR debug/36728
> PR debug/55467
> * cselib.c (cselib_process_insn): If cselib_preserve_constants,
> don't reset table and exit early on volatile insns and setjmp.
> Reset table afterwards on se
On Tue, Nov 27, 2012 at 8:29 PM, Uros Bizjak wrote:
>> As long as volatile asms and UNSPEC_VOLATILE insns (aka.
>> barriers) are handled the same way and consistently throughout
>> gcc, I'm fine. It seems your patch does that, so thanks!
>>
>> > But the question is also what effects your patch c
Hello!
> On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> > On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
>
> JFTR: No I didn't, Eric wrote the below. But, it made sense to me. :)
>
> > > > We apparently have a small conflict between the meaning of volatile
> > > > asms with
> >
On Tue, Nov 27, 2012 at 06:35:52PM +0100, Eric Botcazou wrote:
> Now I agree that the discussion exists for volatile asms. But you have for
> example in the unmodified cse.c:
>
> /* A volatile ASM invalidates everything. */
> if (NONJUMP_INSN_P (insn)
> && GET_CODE (PATTERN (insn)) ==
> I strongly disagree with this. Outputs and clobbers have significant
> meaning even on volatile asms, asm volatile doesn't mean all registers and
> all memory are supposed to be considered clobbered. For memory you have
> "memory" clobber for that, for registers it is users responsibility to
>
On Tue, Nov 27, 2012 at 01:03:47PM +0100, Jakub Jelinek wrote:
> So, at least from var-tracking POV which doesn't attempt to perform any
> optimizations across any insn, just tries to track where values live, IMHO a
> volatile asm acts exactly the same as non-volatile, that is why I'm testing
> fol
On Tue, 27 Nov 2012, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
JFTR: No I didn't, Eric wrote the below. But, it made sense to me. :)
> > > We apparently have a small conflict between the meaning of volatile asms
> > > with
> > > operands at the s
On Tue, Nov 27, 2012 at 06:44:23AM -0500, Hans-Peter Nilsson wrote:
> > We apparently have a small conflict between the meaning of volatile asms
> > with
> > operands at the source level and volatile_insn_p. However, I think that the
> > latter interpretation is the correct one: if your asm state
I quoted the whole discussion, see a single line below.
On Mon, 19 Nov 2012, Eric Botcazou wrote:
> > Unfortunately, it causes regressions; read on for a very brief
> > analysis.
> >
> > For x86_64-linux (base multilib):
> >
> > Running
> > /home/hp/gcctop/tmp/pr55030-2n/gcc/gcc/testsuite/gcc.dg/g
Thanks for the reviews!
On Mon, 19 Nov 2012, Eric Botcazou wrote:
> Thanks for the analysis. I don't think that the redundancy of the clobber
> list matters here: the clobbers are added to all asm statements, volatile or
> not, so they aren't intended to make the volatile statements more precise
> Unfortunately, it causes regressions; read on for a very brief
> analysis.
>
> For x86_64-linux (base multilib):
>
> Running
> /home/hp/gcctop/tmp/pr55030-2n/gcc/gcc/testsuite/gcc.dg/guality/guality.exp
> ... ...
> FAIL: gcc.dg/guality/pr36728-1.c -O1 line 12 arg7 == 30
> [...]
>
> I looked i
On Mon, 12 Nov 2012, Eric Botcazou wrote:
> > This is a target-specific blockage insn, but with the general form
> > found in all targets defining it. The default blockage is an empty
> > asm-volatile, which is what cse_insn recognized. The blockage insn is
> > there to "prevent scheduling" of th
> This is a target-specific blockage insn, but with the general form
> found in all targets defining it. The default blockage is an empty
> asm-volatile, which is what cse_insn recognized. The blockage insn is
> there to "prevent scheduling" of the critical insns and register
> values. It's almo
The problem exposed in PR55030 (repeatable on x86_64-linux with -m32 at
r192676) is that the fake-frame-pointer "frame" is replaced with the
actual-frame-pointer "bp" in cse1, around the critical insn in
__builtin_setjmp_receiver that restores their defined offset. The
patch in PR55030/r192676 rem
19 matches
Mail list logo
