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: [rtl, i386] vec_merge simplification

From: Marc Glisse <marc dot glisse at inria dot fr>
To: Eric Botcazou <ebotcazou at adacore dot com>
Cc: gcc-patches at gcc dot gnu dot org
Date: Tue, 2 Apr 2013 09:53:06 +0200 (CEST)
Subject: Re: [rtl, i386] vec_merge simplification
References: <alpine dot DEB dot 2 dot 02 dot 1303170103230 dot 12359 at stedding dot saclay dot inria dot fr> <8694562 dot qGXxdu6rGm at polaris> <alpine dot DEB dot 2 dot 02 dot 1303301513400 dot 10575 at stedding dot saclay dot inria dot fr> <1976820 dot DEfXo9emmg at polaris>

On Tue, 2 Apr 2013, Eric Botcazou wrote:

Thanks, here is a version taking into account all your comments, and which
still passes bootstrap+testsuite on x86_64-linux-gnu. I am not completely
sure if there is a point checking !side_effects_p (op1) after rtx_equal_p
(op0, op1), but I am still doing it as it seems safe.


It's also done in other cases (IOR, XOR, AND, etc) where we return the first
operand after having found out that the second operand is equal to it.  If the
semantics of VEC_MERGE is to evaluate its operands, then they always need to
be evaluated, whatever the result.

Thanks, I should have checked the other uses indeed... I got confusedbecause at tree level, operand_equal_p implies that there are no sideeffects.


--
Marc Glisse

References:
- Re: [rtl, i386] vec_merge simplification
  - From: Eric Botcazou

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