https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33891|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33912&action=edit
gcc5-pr59708-wip3.patch

After discussions with richi on IRC, I've revamped the patch so that it uses
the
internal calls for all cases through GIMPLE, and only does all the special
casing how to best emit code during expansion.  So, all the
{ADD,SUB,MUL}_OVERFLOW internal calls now can have arbitrary types in the
arguments (signed vs. unsigned, different precision) and the result type is the
type of __real__ of the result.  The advantage of doing that is that we don't
have to decide during gimplification about the best way to emit the more rare
sign/precision combination, and depending on propagation and VRP we can emit
better code.

In this version, I've recoded most of the code I had in builtins.c to be done
during expansion and finished up handling of the last few add/sub cases (signed
+- signed into unsigned and unsigned +- unsigned into signed).  From the
previous patch, what is missing right now is type promotion (i.e. when the
result type is narrower than that of the arguments and the computation needs to
be done in wider mode, then converted to the result mode, sign or zero extended
back and compared to the wider mode result and overflow set if it doesn't
compare equal) which I'll handle tomorrow, and the 4 different cases for
multiplication not handled yet (when multiplication arguments differ or when
they are the same, but result has different sign); plus of course more
testcases and documentation.

Reply via email to