Re: Question about insn predicates and constraints
Andreas Schwab writes:
> m68k.md contains the following insn:
>
> (define_insn ""
> [(set (match_operand:SI 0 "nonimmediate_operand" "=&d")
> (zero_extract:SI (match_operand:SI 1 "register_operand" "do")
>(match_operand:SI 2 "const_int_operand" "n")
>(match_operand:SI 3 "const_int_operand" "n")))]
> "TARGET_68020 && TARGET_BITFIELD
>&& (INTVAL (operands[2]) == 8 || INTVAL (operands[2]) == 16)
>&& INTVAL (operands[3]) % INTVAL (operands[2]) == 0
>&& (GET_CODE (operands[1]) == REG
>|| ! mode_dependent_address_p (XEXP (operands[1], 0),
> MEM_ADDR_SPACE (operands[1])))"
> {
> cc_status.flags |= CC_NOT_NEGATIVE;
> if (REG_P (operands[1]))
> {
> if (INTVAL (operands[2]) + INTVAL (operands[3]) != 32)
> return "bfextu %1{%b3:%b2},%0";
> }
> else
> operands[1]
> = adjust_address (operands[1], SImode, INTVAL (operands[3]) / 8);
>
> output_asm_insn ("clr%.l %0", operands);
> if (GET_CODE (operands[0]) == MEM)
> operands[0] = adjust_address (operands[0],
> INTVAL (operands[2]) == 8 ? QImode : HImode,
> (32 - INTVAL (operands[1])) / 8);
>
> if (INTVAL (operands[2]) == 8)
> return "move%.b %1,%0";
> return "move%.w %1,%0";
> })
>
> It is my understanding that given the register_operand predicate on op1
> it can never be a MEM expressions, thus the call to
> mode_dependent_address_p in the condition is useless, and the "o"
> constraint is redundant.
Worse than redundant really. If the register operand is a spilled pseudo,
"o" allows reload to replace the operand with a stack memory reference,
which would lead to an ICE after reload. (Reload only checks constraints
in that situation, not predicates.)
Which is just a way of saying that there were even more reasons for
making the change you wanted to make...
Richard
Re: Question about insn predicates and constraints
Richard Sandiford writes: > Worse than redundant really. If the register operand is a spilled pseudo, > "o" allows reload to replace the operand with a stack memory reference, > which would lead to an ICE after reload. (Reload only checks constraints > in that situation, not predicates.) What kind of ICE would that be? Perhaps recog complaining that the insn no longer matches? (Since the insn body happily handles a MEM that would not be the problem.) > Which is just a way of saying that there were even more reasons for > making the change you wanted to make... What I really want to find out is the motivation for the original changes in revision 11511. There are similar problems left in vax.md, btw. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Question about insn predicates and constraints
Andreas Schwab writes: > Richard Sandiford writes: >> Worse than redundant really. If the register operand is a spilled pseudo, >> "o" allows reload to replace the operand with a stack memory reference, >> which would lead to an ICE after reload. (Reload only checks constraints >> in that situation, not predicates.) > > What kind of ICE would that be? Perhaps recog complaining that the insn > no longer matches? Right. It would typically trigger during postreload. >> Which is just a way of saying that there were even more reasons for >> making the change you wanted to make... > > What I really want to find out is the motivation for the original > changes in revision 11511. There are similar problems left in vax.md, > btw. Not sure TBH. I think the idea was that memory extractions should be QImode and register extractions should be word_mode, whereas the .md files before that revision seemed to allow other combinations. But I thought that rule applied more to the named ext* and ins* patterns. I'm not sure why the unnamed patterns couldn't be more general. The handling of the constraints in that revision does look a bit odd. Richard
Re: Question about insn predicates and constraints
Thanks for the hints. I'll go with removing the dead bits that assume a MEM operand for now. The ICE appears to be pretty hard to trigger, given how old that change is. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
When did 4.8 fork and where was it forked from ?
Hi, I am trying to find out when 4.8 forked and where it actually forked from ? This information does not seem immediately available. Many thanks in advance, Aaron
Re: When did 4.8 fork and where was it forked from ?
On 30 September 2012 17:26, Aaron Gray wrote: > Hi, > > I am trying to find out when 4.8 forked and where it actually forked from ? It didn't, there is no 4.8 branch yet. > This information does not seem immediately available. See http://gcc.gnu.org/develop.html#timeline for release branches that do exist. 4.8 will be added to it in due course.
Re: When did 4.8 fork and where was it forked from ?
On 30 September 2012 17:30, Jonathan Wakely wrote: > On 30 September 2012 17:26, Aaron Gray wrote: >> Hi, >> >> I am trying to find out when 4.8 forked and where it actually forked from ? > > It didn't, there is no 4.8 branch yet. > >> This information does not seem immediately available. > > See http://gcc.gnu.org/develop.html#timeline for release branches that > do exist. 4.8 will be added to it in due course. If it did exist, you could look in svn to see when the branch was created, e.g. for the 4.7 branch: http://gcc.gnu.org/viewcvs/branches/gcc-4_7-branch/ The first file there shows the branch was created by rev 184777 which was created from rev 184776: http://gcc.gnu.org/viewcvs?view=revision&revision=184777
gcc-4.8-20120930 is now available
Snapshot gcc-4.8-20120930 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120930/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 191879 You'll find: gcc-4.8-20120930.tar.bz2 Complete GCC MD5=0649d1ca6545300cc76ead93a164eae8 SHA1=b93ae01a76b7e141959df42304c7befb742e6ee2 Diffs from 4.8-20120923 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
