This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Revision 144098 (d.d. Wed Feb 11 08:56:41 2009 UTC (4 weeks ago)) is not a regression bug fix.


On Wed, Mar 11, 2009 at 4:00 PM, Toon Moene <toon@moene.org> wrote:
> Steven Bosscher wrote:
>
>> On Wed, Mar 11, 2009 at 11:20 PM, Toon Moene <toon@moene.org> wrote:
>>>
>>> I will abide by the rules - but the rules also say that this is not the
>>> sort
>>> of "fix" that goes in at phase 4.
>>
>> Which rule where says so? Not intended in an offensive manner -- just
>> curious. I'm not aware of any rules that specify what kind of
>> regression can be fixed and how. ?I thought the rule is "fix
>> regressions", not "fix some regressions but not others".
>
> The point is that people want a compiler to generate correct code. ?So any
> regression that produces wrong code in some circumstances is, well, a
> regression.
>
> Now, of course, it is possible that a change to the compiler might result in
> it generating slower code. ?That is also a regression.
>
> Then the challenge is to fix the optimization regression without introducing
> a correctness regression.
>
> Because I bet most of our "customers" would prefer correct answers (within
> the accuracy that the problem at hand requires) over fast, but wrong answers
> (outside the accuracy that the problem at hand requires).
>
> As you can see from the logs I pasted, there are Infinity's and there are
> finite answers.
>
> I can assure you that we, in meteorology, prefer finite answers, because
> they correspond with the real world we observe.
>
> Hope this helps,
>

If you can provide a testcase, I can take a look. If it isn't easy to find
a testcase, please disable the second pattern:

(define_peephole2
  [(set (match_operand 0 "register_operand" "")
        (match_operand 1 "register_operand" ""))
   (set (match_dup 0)
                   (match_operator 3 "commutative_operator"
                     [(match_dup 0)
                      (match_operand 2 "memory_operand" "")]))]
  "operands[0] != operands[1]
   && ((MMX_REG_P (operands[0]) && MMX_REG_P (operands[1]))
       || (SSE_REG_P (operands[0]) && SSE_REG_P (operands[1])))"
  [(set (match_dup 0) (match_dup 2))
   (set (match_dup 0)
        (match_op_dup 3 [(match_dup 0) (match_dup 1)]))]
  "")

to see if it makes a difference.

Thanks.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]