This is the mail archive of the gcc-patches@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: ifcvt/crossjump patch: Fix PR 42496, 21803


On 07/28/2010 10:35 AM, Eric Botcazou wrote:
>> What exactly is gained by that?  Certainly not readability.
> 
> Avoiding kludges like the one I already mentioned.

As I already pointed out, it's
a) not a kludge, but quite necessary and done like that elsewhere
b) not avoided by pretending a reorder_insns operation is a CFG operation.

Hence, your comment makes no sense.  You've never replied with anything
of substance to either point a) or point b).

>> You're moving insns, so reorder_insns is the correct API.  The suggestion is
>> obviously absurd in my eyes.
> 
> The first sentence is equally absurd these days because of CFG layout mode.

Explain how that is relevant to the current discussion.  I believe it's
completely beside the point, as that's only concerned with the layout of
basic blocks, not with the placement of insns within them.  Moving insns
from one basic block to another (while explicitly avoiding touching
things like final jump insns) doesn't affect that, so IMO you're still
not making any sense.

Maybe that's the thing you're missing?  No control flow insns are ever
touched or moved at all by the patch.  The CFG is in every case the same
afterwards as it was before (although it may be cleaned up, but that's a
different job done already by the other code in cfglcleanup).  That's a
pretty strong hint that we're not dealing with a CFG operation.

Your attempts at patch review for this issue all have been drive-by
one-liners like this, which were at best insufficiently explained, and
at worst completely nonsensical.  It has been extremely frustrating.


Bernd


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