Re: add_branch_dependences in sched-rgn.c
On Apr 9, 2014, at 4:15 AM, Kyrill Tkachov wrote: > Hi all, > > I'm looking at some curious pre-reload scheduling behaviour and I noticed > this: > > At the add_branch_dependences function sched-rgn.c there is a comment that > says "branches, calls, uses, clobbers, cc0 setters, and instructions that can > throw exceptions" should be scheduled at the end of the basic block. > > However right below it the code that detects this kind of insns seems to only > look for these insns that are directly adjacent to the end of the block > (implemented with a while loop that ends as soon as the current insn is not > one of the aforementioned). > > Shouldn't the code look through the whole basic block, gather all of the > branches, clobbers etc. and schedule them at the end? > Not really. The instruction sequences mentioned in the comment end basic block by definition -- if there is a jump or other "special" sequence, then basic block can't continue beyond that as control may be transffered to something other than the next instruction. Add_branch_dependencies() makes sure that scheduler does not "accidentally" place something after those "special" sequences thus creating a corrupted basic block. -- Maxim Kuvyrkov www.linaro.org
[GSoC] Status - 20140410
Community, [and BCC'ed mentors] Google Summer of Code is panning out nicely for GCC. We have received 5 slots for GSoC projects this year. The plan is to accept 5 top-rated student proposals. If you haven't rated the projects yet, you have 2 days to go to GSoC website [1] and rate the proposals. I will mark the top-5 proposals "Accepted" this Friday/Saturday. We already have mentors volunteered for the 5 currently leading projects, which is great. We also need a couple of backup mentors in case one of the primary mentors becomes temporarily unavailable. Your main job as backup mentor will be to follow 2-5 of the student projects and be ready to step in, should a need arise. Any volunteers for the roles of backup mentors? I will send the next GSoC update early next week [when student projects are accepted]. Thank you, [1] https://www.google-melange.com/gsoc/homepage/google/gsoc2014 -- Maxim Kuvyrkov www.linaro.org
Re: Unable to match instruction pattern
Found it ...
I had
(define_expand "zero_extendhisi2"
[
(set (subreg:HI (match_operand:SI 0 "general_operand" "")0)
(match_operand:HI 1 "general_operand" ""))
(set (subreg:HI (match_dup 0)2)
(const_int 0))
]
""
""
)
which creates the subregs and performs the zero extension in a cpu
agnostic manner... possibly leaving the contents of registers known and
available for future use by optimizations. I was caught by this ...
gcc trunk
recog.c:1016
/* Avoid memories with nonzero SUBREG_BYTE, as offsetting the
memory
may result in incorrect reference. We should simplify all
valid
subregs of MEM anyway. But allow this after reload because we
might be called from cleanup_subreg_operands.
??? This is a kludge. */
if (!reload_completed && SUBREG_BYTE (op) != 0
&& MEM_P (sub))
return 0;
Which causes failure to recognize the second "(set (subeg...))" as a
mov<> expansion. I used gdb to set reload_completed true temporarily and
the correct match to mov<> was found and correct code generated. I don't
know if the mentioned kludge refers to the need to avoid other than
suibreg(() 0 ) or to the fact that more elegant alignment checking could
be used to allow valid subreg constructs.
So, I replaced my (define_expand "zero_extendhisi2") with a cpu specific
((define_insn "zero_extendhisi2") which works but doesn't expose as much
info for post reload cleanup.
Paul.
El 09/04/14 00:23, Paul Shortis escribió:
I'm porting gcc to a 16 bit processor. Occasionally compiling source
such as
short v1;
long global;
global = (long)v1;
results in ...
(insn 11 10 12 2 (set (subreg:HI (mem/c:SI (symbol_ref:HI ("global")
) [2 global+0 S4 A16]) 2)
(const_int 0 [0])) t.c:15 -1
(nil))
(insn 12 11 13 2 (set (subreg:HI (mem/c:SI (symbol_ref:HI ("global")
) [2 global+0 S4 A16]) 0)
(reg:HI 24 [ D.1348 ])) t.c:15 -1
(nil))
The second of these instructions successfully matches a movhi pattern
which is found via the define_expand below
;the INTEGER iterator includes [QI HI SI]
(define_expand "mov"
[(set (match_operand:INTEGER 0 "nonimmediate_operand" "")
(match_operand:INTEGER 1 "general_operand" ""))]
""
{
if( can_create_pseudo_p() )
{
if( !register_operand( operands[0], mode )
&& !register_operand( operands[1], mode ))
{
/* one of the operands must be in a register. */
operands[1] = copy_to_mode_reg (mode,
operands[1]);
}
}
However the first instruction fails to match and be expanded so that
the const_int is forced into a register. I defined an instruction
which is an exact match
(define_insn "*storesic"
[
(set (subreg:HI (mem:SI (match_operand:HI 0 "symbol_ref_operand"
"")) 2)
(match_operand:HI 1 "const_int_operand"))
]
This matches, however I need a scratch register (R? below) to
transform this into
loadR?, const_int_operand
store R?, address
and as soon as I add the match_scratch
(clobber(match_scratch:HI 2 "=r"))
the pattern no longer matches because expand calls recog() with
pnum_clobbers = 0 (NULL)
I a similar vein to the way CC setting instructions are handled I
tried defining a second instruction containing the required
match_scratch prior to the define_insn "*storesic" (see above) in the
hope that it may match subsequent to the expand pass, however it is
never seen.
Can anyone offer any insight to what I'm doing wrong and how I might
proceed ?
Thanks, Paul.
