This is the mail archive of the
mailing list for the GCC project.
Re: Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 11 Dec 2014 09:30:41 -0600
- Subject: Re: Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci28yN6LdctRik9Tex8D-XKG8D=oFKdYs7RbqGXDqipqT1Q at mail dot gmail dot com>
On Thu, Dec 11, 2014 at 03:13:50PM +0800, Bin.Cheng wrote:
> So I am wondering if I can rely on INSN_LUID checking orders of
> difference instruction. If it can be done, I can easily differentiate
> live range shrink and extend.
> Further question is, if we don't insert new insns, can I use INSN_LUID
> safely for this purpose?
I0 is before I1 is before I2 is before I3; one of the first things
try_combine does is make sure this is true (by swapping the names
around if necessary).
The LUIDs are in strictly increasing order, and they stay that way:
combine never moves or inserts insns.