LTO bootstrap failure for GCC-5 prerelease.
See: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-uninit.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-loop-ivcanon.o differs ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LTO bootstrap failure for GCC-5 prerelease.
On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote: > See: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html > > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Bootstrap comparison failure! > gcc/tree-ssa-uninit.o differs > gcc/tree-switch-conversion.o differs > gcc/tree-ssa-loop-ivcanon.o differs With LTO bootstrap you run into PR62077, can you try the workaround, --enable-stage1-checking=release? Richard. > ... > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_BASIC_BLOCK 5
32: [r6:SI]=r4:SI
REG_DEAD r6:SI
REG_DEAD r4:SI
33: [r5:SI]=r0:SI
REG_DEAD r5:SI
REG_DEAD r0:SI
7: r0:SI=0
REG_EQUAL 0
85: use r0:SI
86:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
77: barrier
46: L46:
45: NOTE_INSN_BASIC_BLOCK 6
8: r0:SI=r4:SI
REG_DEAD r4:SI
REG_EQUAL 0x
87: use r0:SI
88:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
79: barrier
54: L54:
53: NOTE_INSN_BASIC_BLOCK 7
9: r0:SI=0x <== lost REG_EQUAL after patch
34: L34:
35: NOTE_INSN_BASIC_BLOCK 8
41: use r0:SI
90:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
89: barrier
try_forward_edges(remove basic block 6) fail by try_crossjump_bb didn't occur.
try_crossjump_bb (remove insns in basic block 6) fail by comparison
between insn 9 and insn 8 not eqaul.
The comparison in function can_replace_by use REG_EQUAL to compare
register content.
The REG_EQAUL lost in insn 9, so the comparison fail.
But we may still have chance to remove basic block 6 in this case.
Because right hand value of insn 9 is already a constant.
We could get comparison equal by comparing between insn 8's register
note and insn 9's RHS if RHS is a constant integer.
Possible patch for can_replace_by in cfgcleanup.c.
- if (!note1 || !note2 || !rtx_equal_p (XEXP (note1, 0), XEXP (note2, 0))
- || !CONST_INT_P (XEXP (note1, 0)))
+
+ if (!note1 || !CONST_INT_P (XEXP (note1, 0)))
return dir_none;
+ if (note2)
+{
+ if (!rtx_equal_p (XEXP (note1, 0), XEXP (note2, 0)))
+ return dir_none;
+}
+ else
+{
+ if (!CONST_INT_P (SET_SRC (s2))
+ || !rtx_equal_p (XEXP (note1, 0), SET_SRC (s2)))
+ return dir_none;
+}
+
I'm not sure the idea is ok or it might crash something.
Any suggestion would be very helpful.
Thanks in advance.
Shiva Chen
Re: PR63633: May middle-end come up width hard regs for insn expanders?
I allowed me to CC Vladimir; maybe he can propose how the backend can describe
an efficient, constraint-based solution. The problem is about expanders
producing insns with non-fixed hard-regs as in/out operands or clobbers. This
includes move insn from non-generic address spaces which require dedicated hard
regs. Issue is about correctness and efficiency of generated code.
Am 10/24/2014 um 08:29 PM schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit tedious,
but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart for HI division by const_int. Cheating with costs did not
help. However for now I am mostly after correct, ICE-less code.
What I am concerned about is:
1) May it happen that a value lives in a hard-reg across the expander? The
expander has no means to detect that situation and interfere, e.g.
hard-reg = source_value // middle-end
expand-code // back-end
sink_value = hard-reg // middle-end
where "expand-code" is one defind_expand / define_insn that clobbers /
changes (parts of) hard-reg but does *not* get hard-reg as operand. This is
wrong code obviously.
It can happen, but if it happens, that would mean user code bug, like using
register asm with an register that is unsuitable for use as global or local
register var on the target, or it could be backend bug (expansion of some
pattern clobbering register that has other fixed uses).
You shouldn't ICE on it, but what happens is undefined.
Before RA, the use of hard regs should be limited (pretty much just fixed
regs where really necessary, global and local register variables (user needs
to use with care), function arguments and return values (short lived around
the call patterns).
Jakub
FYI, the problem with using hard regs returned, now as PR65657 with move insns
which use hard regs.
There is one simple and obvious solution : Don't use hard regs, but instead
introduce respective constraints and let the register allocator do the job of
allocating the hard regs.
I tried that and it works in principle (for non-moves), but the code generated
by the register allocator is *bloated* beyond all recognition.
The use of hard regs in the avr BE is motivated by avoiding standard ABI calls
for support functions. Many of these libgcc functions are written in assembly
and have a much smaller footprint than ordinary ABI functions. The move insns
mentioned above perform loading from a non-standard address-sppace which is too
complicated to be expanded inline -- and even if expanded inline, the code will
need specific hard registers in specific operands because the instruction set
is dictating that.
Bottom line is: Using that simple and obvious hard-regs-by-constraint approach
would lead to code that is not acceptable w.r.t its performance.
One only solution that might work without bloating the code as mad might be to
perform the register selection by hand in a dedicated, pre-reload,
target-specific pass as outlined in
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00823.html
Johann
Index: gcc-4_9-branch/gcc/config/avr/avr.md
===
--- gcc-4_9-branch/gcc/config/avr/avr.md (revision 221321)
+++ gcc-4_9-branch/gcc/config/avr/avr.md (working copy)
@@ -165,6 +165,13 @@ (define_attr "isa"
standard"
(const_string "standard"))
+
+(define_attr "fixregs"
+ "xload_A, xloadQI_A,
+ no"
+ (const_string "no"))
+
+
(define_attr "enabled" ""
(cond [(eq_attr "isa" "standard")
(const_int 1)
@@ -494,9 +501,9 @@ (define_insn "load__libgcc"
;; "xload8qi_A"
;; "xload8qq_A" "xload8uqq_A"
(define_insn_and_split "xload8_A"
- [(set (match_operand:ALL1 0 "register_operand" "=r")
-(match_operand:ALL1 1 "memory_operand""m"))
- (clobber (reg:HI REG_Z))]
+ [(set (match_operand:ALL1 0 "register_operand" "=r")
+(match_operand:ALL1 1 "memory_operand" "m"))
+ (clobber (match_operand:HI 2 "scratch_operand" "=z"))] ;; HI 30
"can_create_pseudo_p()
&& !avr_xload_libgcc_p (mode)
&& avr_mem_memx_p (operands[1])
@@ -505,6 +512,8 @@ (define_insn_and_split "xload8_A"
"&& 1"
[(clobber (const_int 0))]
{
+gcc_assert (SCRATCH != GET_CODE (operands[2]));
+
/* ; Split away the high part of the address. GCC's register allocator
; in not able to allocate segment registers and reload the resulting
; expressions. Notice that no address register can hold a PSImode. */
@@ -520,7 +529,9 @@ (define_insn_and_split "xload8_A"
set_mem_addr_space (SET_SRC (single_set (insn)),
MEM_ADDR_SPACE (operands[1]));
DONE;
- })
+ }
+ [(set_attr "fixregs" "xloadQI_A")])
+
;; "xloadqi_A" "xloadqq_A" "xloaduqq_A"
;; "xloadhi_A" "xloadhq_A" "xloaduhq_A" "xloadha_A" "xloaduha_A"
@@ -530,9 +541,9 @@ (defi
Re: LTO bootstrap failure for GCC-5 prerelease.
On 04/17/2015 10:49 AM, Richard Biener wrote: On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote: See: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-uninit.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-loop-ivcanon.o differs With LTO bootstrap you run into PR62077, can you try the workaround, --enable-stage1-checking=release? Richard. Yep, that worked: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02034.html Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
IRA preferencing issues
Hi, While investigating why the IRA preferencing algorithm often chooses incorrect preferences from the costs, I noticed this thread: https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html I am seeing the exact same issue on AArch64 - during the final preference selection ira-costs takes the union of any register classes that happen to have equal cost. As a result many registers get ALL_REGS as the preferred register eventhough its cost is much higher than either GENERAL_REGS or FP_REGS. So we end up with lots of scalar SIMD instructions and expensive int<->FP moves in integer code when register pressure is high. When the preference is computed correctly as in the proposed patch (choosing the first class with lowest cost, ie. GENERAL_REGS) the resulting code is much more efficient, and there are no spurious SIMD instructions. Choosing a preferred class when it doesn't have the lowest cost is clearly incorrect. So is there a good reason why the proposed patch should not be applied? I actually wonder why we'd ever need to do a union - if there are 2 classes with equal cost, you'd use the 2nd as the alternative class. The other question I had is whether there is a good way to get improve the preference in cases like this and avoid classes with equal cost altogether. The costs are clearly not equal: scalar SIMD instructions have higher latency and require extra int<->FP moves. It is possible to mark variants in the MD patterns using '?' to discourage them but that seems like a hack, just like '*'. Is there a general way to say that GENERAL_REGS is preferred over FP_REGS for SI/DI mode? Wilco
Questions about C as used/implemented in practice
Dear gcc list, we are trying to clarify what behaviour of C implementations is actually relied upon in modern practice, and what behaviour is guaranteed by current mainstream implementations (these are quite different from the ISO standards, and may differ in different contexts). Focussing on the sequential behaviour of memory operations, we've collected a short survey of 15 questions about C: http://goo.gl/iFhYIr Your answers to these would be very helpful, especially if you can speak authoritatively about what gcc does (it's difficult for us to directly investigate the emergent properties of the combination of optimisations in a production compiler). This continues a research project at the University of Cambridge; in earlier work (with Batty, Owens, and Sarkar) we addressed the C/C++11 concurrency model, which resulted in fixes to the ISO standards and supports work on compiler testing (by Zappa Nardelli, Morisset, and Pawan). many thanks, Kayvan Memarian and Peter Sewell
RE: IRA preferencing issues
Wilco Dijkstra writes: > While investigating why the IRA preferencing algorithm often chooses > incorrect preferences from the costs, I noticed this thread: > https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html > > I am seeing the exact same issue on AArch64 - during the final > preference selection ira-costs takes the union of any register classes > that happen to have equal cost. As a result many registers get ALL_REGS > as the preferred register eventhough its cost is much higher than either > GENERAL_REGS or FP_REGS. So we end up with lots of scalar SIMD > instructions and expensive int<->FP moves in integer code when register > pressure is high. When the preference is computed correctly as in the > proposed patch (choosing the first class with lowest cost, ie. > GENERAL_REGS) the resulting code is much more efficient, and there are > no spurious SIMD instructions. > > Choosing a preferred class when it doesn't have the lowest cost is > clearly incorrect. So is there a good reason why the proposed patch > should not be applied? I actually wonder why we'd ever need to do a > union - if there are 2 classes with equal cost, you'd use the 2nd as the > alternative class. > > The other question I had is whether there is a good way to get improve > the preference in cases like this and avoid classes with equal cost > altogether. The costs are clearly not equal: scalar SIMD instructions > have higher latency and require extra int<->FP moves. It is possible to > mark variants in the MD patterns using '?' to discourage them but that > seems like a hack, just like '*'. Is there a general way to say that > GENERAL_REGS is preferred over FP_REGS for SI/DI mode? MIPS has the same problem here and we have been looking at ways to address it purely via costings rather than changing IRA. What we have done so far is to make the cost of a move from GENERAL_REGS to FP_REGS more expensive than memory if the move has an integer mode. The goal for MIPS is to never allocate an FP register to an integer mode unless it was absolutely necessary owing to an integer to fp conversion where the integer has to be put in an FP register. Ideally I'd like a guarantee that FP registers will never be used unless a floating point type is present in the source but I haven't found a way to do that given the FP-int conversion issue requiring SImode to be allowed in FP regs. The patch for MIPS is not submitted yet but has eliminated the final two uses of FP registers when building the whole Linux kernel with hard-float enabled. I am however still not confident enough to say you can build integer only code with hard-float and never touch an FP register. Since there are multiple architectures suffering from this I guess we should look at properly addressing it in generic code. Thanks, Matthew
Re: Questions about C as used/implemented in practice
> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote: > > Dear gcc list, > > we are trying to clarify what behaviour of C implementations is > actually relied upon in modern practice, and what behaviour is > guaranteed by current mainstream implementations (these are quite > different from the ISO standards, and may differ in different > contexts). I’m not sure what you mean by “guaranteed”. I suspect what the GCC team will say is guaranteed is “what the standard says”. If by “guaranteed” you mean the behavior that happens to be implemented in a particular version of the compiler, that may well be different, as you said. But it’s also not particularly meaningful, because it is subject to change at any time subject to the constraints of the standard, and is likely to be different among different versions, and for that matter among different target architectures and of course optimization settings. paul
Re: Questions about C as used/implemented in practice
On 17 April 2015 at 15:19, wrote: > >> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote: >> >> Dear gcc list, >> >> we are trying to clarify what behaviour of C implementations is >> actually relied upon in modern practice, and what behaviour is >> guaranteed by current mainstream implementations (these are quite >> different from the ISO standards, and may differ in different >> contexts). > > I’m not sure what you mean by “guaranteed”. > > I suspect what the GCC team will say is guaranteed is “what the standard > says”. If that's really true, that will be interesting, but there may be areas where (a) current implementation behaviour is stronger than what the ISO standards require, and (b) important code relies on that behaviour to such an extent that it becomes pragmatically infeasible to change it. Such cases are part of what we're trying to discover here. There are also cases where the ISO standards are unclear or internally inconsistent. > If by “guaranteed” you mean the behavior that happens to be implemented in a > particular version of the compiler, that may well be different, as you said. > But it’s also not particularly meaningful, because it is subject to change at > any time subject to the constraints of the standard, and is likely to be > different among different versions, and for that matter among different > target architectures and of course optimization settings. Some amount of variation has to be allowed, of course - in fact, what we'd like to clarify is really the envelope of allowable variation, and that will have to be parametric on at least some optimisation settings. > paul >
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Tue, 14 Apr 2015 08:09:05 +0200, Jan Kratochvil wrote:
> On Fri, 10 Apr 2015 14:31:45 +0200, Jan Kratochvil wrote:
> > What is the recommended fix? I expect pointer to a declaration / opaque
> > type
> > which gets completed only when one references the 'p' field later?
>
> It looks as it got fixed by:
It did not.
As I was told the mail was unclear - to simplify the question:
How to get 'volatile struct sv' GCC 'tree' type for:
volatile struct sv { volatile struct sv *p; };
Thanks,
Jan
RE: IRA preferencing issues
> Matthew Fortune wrote: > Wilco Dijkstra writes: > > While investigating why the IRA preferencing algorithm often chooses > > incorrect preferences from the costs, I noticed this thread: > > https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html > > > > I am seeing the exact same issue on AArch64 - during the final > > preference selection ira-costs takes the union of any register classes > > that happen to have equal cost. As a result many registers get ALL_REGS > > as the preferred register eventhough its cost is much higher than either > > GENERAL_REGS or FP_REGS. So we end up with lots of scalar SIMD > > instructions and expensive int<->FP moves in integer code when register > > pressure is high. When the preference is computed correctly as in the > > proposed patch (choosing the first class with lowest cost, ie. > > GENERAL_REGS) the resulting code is much more efficient, and there are > > no spurious SIMD instructions. > > > > Choosing a preferred class when it doesn't have the lowest cost is > > clearly incorrect. So is there a good reason why the proposed patch > > should not be applied? I actually wonder why we'd ever need to do a > > union - if there are 2 classes with equal cost, you'd use the 2nd as the > > alternative class. > > > > The other question I had is whether there is a good way to get improve > > the preference in cases like this and avoid classes with equal cost > > altogether. The costs are clearly not equal: scalar SIMD instructions > > have higher latency and require extra int<->FP moves. It is possible to > > mark variants in the MD patterns using '?' to discourage them but that > > seems like a hack, just like '*'. Is there a general way to say that > > GENERAL_REGS is preferred over FP_REGS for SI/DI mode? > > MIPS has the same problem here and we have been looking at ways to address > it purely via costings rather than changing IRA. What we have done so > far is to make the cost of a move from GENERAL_REGS to FP_REGS more > expensive than memory if the move has an integer mode. The goal for MIPS > is to never allocate an FP register to an integer mode unless it was > absolutely necessary owing to an integer to fp conversion where the > integer has to be put in an FP register. Ideally I'd like a guarantee > that FP registers will never be used unless a floating point type is > present in the source but I haven't found a way to do that given the > FP-int conversion issue requiring SImode to be allowed in FP regs. I adjusted the costs like that already on AArch64 but while this reduced the crazy spilling of integer values to FP registers and visa versa, it doesn't fix it completely. However it should not be necessary to lie about the move cost and use an unrealistically high value to get decent code... There are other issues in ira-costs that cause preferences to be incorrect: you'll find that after you increase the move costs that explicit int<->fp moves start to go via memory due to memory cost being hardcoded as 1 if an instruction pattern contains 'm' somewhere - oops... I also posted a patch that fixes the preference for new registers created by live-range splitting. > The patch for MIPS is not submitted yet but has eliminated the final > two uses of FP registers when building the whole Linux kernel with > hard-float enabled. I am however still not confident enough to say > you can build integer only code with hard-float and never touch an FP > register. Correct, as long as the preference calculations are not correct and there is no good way to influence the costs reliably, GCC will continue to use FP registers in cases when it shouldn't. It's obvious that integer operations should prefer integer registers and FP operations FP registers, so why is there no easy way to tell GCC?!? > Since there are multiple architectures suffering from this I guess we > should look at properly addressing it in generic code. Agreed. Wilco
Re: Questions about C as used/implemented in practice
On 04/17/2015 09:01 AM, Peter Sewell wrote: On 17 April 2015 at 15:19, wrote: On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote: Dear gcc list, we are trying to clarify what behaviour of C implementations is actually relied upon in modern practice, and what behaviour is guaranteed by current mainstream implementations (these are quite different from the ISO standards, and may differ in different contexts). I’m not sure what you mean by “guaranteed”. I suspect what the GCC team will say is guaranteed is “what the standard says”. If that's really true, that will be interesting, but there may be areas where (a) current implementation behaviour is stronger than what the ISO standards require, and (b) important code relies on that behaviour to such an extent that it becomes pragmatically infeasible to change it. Such cases are part of what we're trying to discover here. There are also cases where the ISO standards are unclear or internally inconsistent. Implementations can and often do provide stronger guarantees than the standards require. When the do, they must be documented in order to be safely relied on. This is termed as implementation-defined behavior in standards. Standards may be unclear to casual readers but they must be consistent and unambiguous. When they're not it's a defect that should be raised against them. If by “guaranteed” you mean the behavior that happens to be implemented in a particular version of the compiler, that may well be different, as you said. But it’s also not particularly meaningful, because it is subject to change at any time subject to the constraints of the standard, and is likely to be different among different versions, and for that matter among different target architectures and of course optimization settings. Some amount of variation has to be allowed, of course - in fact, what we'd like to clarify is really the envelope of allowable variation, and that will have to be parametric on at least some optimisation settings. All the questions in the survey that can be are answered are answered without unambiguity in the C standard (either as well- defined behavior - 4, 5, 11, 12, 15, unspecified - 1, 13, or undefined - 2, 3, 7, 8, 9, 10, 14). There are no optimization options that affect the answers. Martin paul
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 04/17/2015 03:57 AM, Shiva Chen wrote:
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_BASIC_BLOCK 5
32: [r6:SI]=r4:SI
REG_DEAD r6:SI
REG_DEAD r4:SI
33: [r5:SI]=r0:SI
REG_DEAD r5:SI
REG_DEAD r0:SI
7: r0:SI=0
REG_EQUAL 0
85: use r0:SI
86:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
77: barrier
46: L46:
45: NOTE_INSN_BASIC_BLOCK 6
8: r0:SI=r4:SI
REG_DEAD r4:SI
REG_EQUAL 0x
87: use r0:SI
88:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
79: barrier
54: L54:
53: NOTE_INSN_BASIC_BLOCK 7
9: r0:SI=0x <== lost REG_EQUAL after patch
34: L34:
35: NOTE_INSN_BASIC_BLOCK 8
41: use r0:SI
90:
{return;sp:SI=sp:SI+0x18;r3:SI=[sp:SI];r4:SI=[sp:SI+0x4];r5:SI=[sp:SI+0x8];r6:SI=[sp:SI+0xc];r7:SI=[sp:SI+0x10];pc:SI=[sp:SI+0x14];}
REG_UNUSED pc:SI
REG_UNUSED r3:SI
REG_CFA_RESTORE r7:SI
REG_CFA_RESTORE r6:SI
REG_CFA_RESTORE r5:SI
REG_CFA_RESTORE r4:SI
REG_CFA_RESTORE r3:SI
89: barrier
Intead of the slim dump, can you please include the full RTL dump. I
find those much easier to read.
Possible patch for can_replace_by in cfgcleanup.c.
- if (!note1 || !note2 || !rtx_equal_p (XEXP (note1, 0), XEXP (note2, 0))
- || !CONST_INT_P (XEXP (note1, 0)))
+
+ if (!note1 || !CONST_INT_P (XEXP (note1, 0)))
return dir_none;
+ if (note2)
+{
+ if (!rtx_equal_p (XEXP (note1, 0), XEXP (note2, 0)))
+ return dir_none;
+}
+ else
+{
+ if (!CONST_INT_P (SET_SRC (s2))
+ || !rtx_equal_p (XEXP (note1, 0), SET_SRC (s2)))
+ return dir_none;
+}
+
I'm not sure the idea is ok or it might crash something.
Any suggestion would be very helpful.
Seems like you're on a reasonable path to me. I suggest you stick with it.
Basically what it appears you're trying to do is unify insns from
different blocks where one looks like
(set x y) with an attached REG_EQUAL note
And the other looks like
(set x const_int)
Where the REG_EQUAL note has the same value as the const_int in the
second set.
I think you'd want to handle both cases i1 has the note i2, no note and
i1 has no note and i2 has a note.
Jeff
jeff
Re: try_merge_delay_insn with delay list > 1
On 03/10/2015 07:40 AM, BELBACHIR Selim wrote: Me again :) I enhanced my patch because it was not generalized for instructions with N delay_slots. Mostly OK, though there are some formatting nits that need to be corrected. We have whitespace around arithmetic, logical and comparison operators to separate them from their operands. So instead of slot_number+j Use slot_number + j Instead of j=1 Use j = 1 Lines should be wrapped at 80 columns. So you end up with something like this foo (argument1, argument2, argument3) ie, when you wrap, the arguments to the call will line up vertically. It may help wrapping to create a local variable to hold PATTERN (insn). Call it 'pat' :-) When referring to variables or parameters in a comment, capitalize them. The patch may need updating for the trunk, please test it with the trunk when you ask for it to be included on the trunk. These are all fairly minor issues. The actual change seems reasonable. What systems do you have that you could do a bootstrap and regression test with? Ideally since you're changing the delay slot branching code it'd be a system with delay slots :-) If that's not possible because you don't have access to a bootstrapping system with delay slots, make sure to mention it. Ideally you'd have a test for this bug. However, with a private port I wouldn't consider it a necessity. However, you may want to go ahead and create one for internal uses. And if you ever submit your port to the offficial sources, you can include target specific tests at that time.
Re: Questions about C as used/implemented in practice
On 17 April 2015 at 17:03, wrote: > On 04/17/2015 09:01 AM, Peter Sewell wrote: >> >> On 17 April 2015 at 15:19, wrote: >>> >>> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote: Dear gcc list, we are trying to clarify what behaviour of C implementations is actually relied upon in modern practice, and what behaviour is guaranteed by current mainstream implementations (these are quite different from the ISO standards, and may differ in different contexts). >>> >>> >>> I’m not sure what you mean by “guaranteed”. >>> >>> I suspect what the GCC team will say is guaranteed is “what the standard >>> says”. >> >> >> If that's really true, that will be interesting, but there may be >> areas where (a) current implementation behaviour is stronger than what >> the ISO standards require, and (b) important code relies on that >> behaviour to such an extent that it becomes pragmatically infeasible >> to change it. Such cases are part of what we're trying to discover >> here. There are also cases where the ISO standards are unclear or >> internally inconsistent. > > > Implementations can and often do provide stronger guarantees than > the standards require. When the do, they must be documented in order > to be safely relied on. This is termed as implementation-defined > behavior in standards. The cases where the ISO standard explicitly identifies implementation-defined behaviour are generally unproblematic. The cases we're asking about, on the other hand, are typically cases which ISO declares to be undefined behaviour (sometimes for historical reasons relating to now-obsolete implementations) but where some code does depend on particular implementation behaviour. We are trying to identify and bound those cases. > Standards may be unclear to casual readers but they must be consistent > and unambiguous. > When they're not it's a defect that should be raised > against them. Yes, that's true - and we have in the past worked with the C++ and C standards committees, to fix inconsistencies in the concurrency model. But more than that, standards (including any implementation-specific documentation) and common practice have to be sufficiently in sync that the two work together: the former should give strong enough guarantees to support normal usage, and implementations should be sound with respect to them. For some aspects of C, we are currently quite some way from that. >> >>> If by “guaranteed” you mean the behavior that happens to be implemented >>> in a particular version of the compiler, that may well be different, as you >>> said. But it’s also not particularly meaningful, because it is subject to >>> change at any time subject to the constraints of the standard, and is likely >>> to be different among different versions, and for that matter among >>> different target architectures and of course optimization settings. >> >> >> Some amount of variation has to be allowed, of course - in fact, what >> we'd like to clarify is really the envelope of allowable variation, >> and that will have to be parametric on at least some optimisation >> settings. > > > All the questions in the survey that can be are answered are > answered without unambiguity in the C standard (either as well- > defined behavior - 4, 5, 11, 12, 15, unspecified - 1, 13, or > undefined - 2, 3, 7, 8, 9, 10, 14). We are really not asking about what the ISO standard says, but rather about what can be and what is relied upon in practice. (That said, our reading of the standard differs on several of those points.) Peter > There are no optimization > options that affect the answers. > Martin > >> >>> paul >>> >
