This is the mail archive of the
mailing list for the GCC project.
Re: [patch] clean up pdp11.md a bit
On Tue, Feb 14, 2012 at 11:51 PM, Richard Henderson <firstname.lastname@example.org> wrote:
> On 02/14/2012 02:08 PM, Steven Bosscher wrote:
>> OK for trunk?
> This can wait for stage1.
>> +;; On PDP-11, DIV always produces a quotient and a remainder. ?But CSE
>> +;; cannot optimize the divmods away because the SET_DESTs are SUBREGs.
>> ?;(define_expand "divmodhi4"
>> ?; ?[(parallel [(set (subreg:HI (match_dup 1) 0)
> Which of course begs the question of why that's so.
> The division patterns can be modeled similarly to s390.
That is what Ian also said on IRC, but I didn't want to go that far (I
didn't think this basically cosmetic change would be a problem for
stage4 but rewriting patterns, even for a pet target like this, didn't
Anyway, history for this goes back a long long time:
The previous div/mod/divmod patterns didn't have subregs. For example:
- [(set (match_dup 3)
- (sign_extend:SI (match_operand:HI 1 "general_operand" "g")))
- (set (match_operand:HI 0 "general_operand" "g")
- (match_dup 3)
- (sign_extend:SI (match_operand:HI 2 "general_operand" "g")))))]
- "operands = gen_reg_rtx (SImode);")
Not sure why this was changed. What I'd like to do, is remove the
divhi3 and movhi3 define_expand and define_insn, and just keep
divmodhi4. You point to s390. I suppose you mean the divmoddi4
> Indeed, all of the appearances of subreg in the md file are errors:
I was only playing with your match_flags patches. I get the feeling I
am going to regret that... :-)
> Should be removed as unnecessary:
> ?(define_expand "truncsihi2"
> Should be removed as generated by generic code:
> ?(define_insn "zero_extendqihi2"
> ?(define_expand "zero_extendhisi2"
What do you mean with "generated by generic code"?
And the define_insn has to stay, surely?
Thanks, and sorry for the novice questions!