llvm dev - Oct 2015 - Register Spill Caused by the Reassociation

> Date: Fri, 02 Oct 2015 10:40:04 -0700
> From: Gerolf Hoflehner via llvm-dev <llvm-dev at lists.llvm.org>
> To: Sanjay Patel <spatel at rotateright.com>
> Cc: "spatel+llvm at rotateright.com" <spatel+llvm at
rotateright.com>,
> 	llvm-dev <llvm-dev at lists.llvm.org>, Haicheng Wu
> 	<haicheng at codeaurora.com>
> Subject: Re: [llvm-dev] Register Spill Caused by the Reassociation
> 	pass
> Message-ID: <DE90E812-306F-4D8D-9D9F-D92AAF9A29EE at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> This conflict is with many optimizations incl. copy prop, coalescing,
> hoisting etc. Each could increase register pressure and with similar
> impact.  Attempts to control the register pressure locally (within an
> optimization pass) tend to get hard to tune and maintain. Would it be a
> better way to describe eg in metadata how to undo an optimization?
> Optimizations that attempt to reduce pressure like splitting or remat
> could be hooked up and call an undo routine based on a cost model.
>
> I think there is time to do something longer term. This particular
> instance can only be an issue under -fast-math.
>
Agree that it is time do something longer term. We have observed increases
in register pressure and spills due to LICM and PRE as well. The
experience with other compilers suggests that while live range splitting,
rematerialization and other regalloc-related techniques are valuable,
relying on regalloc only to handle register pressure is usually not
sufficient.

Would undoing an entire optimization be reasonable? My preference is for
developing a cost model of register pressure and using it by optimizations
to guide their aggressiveness, for example, hoisting only a subset of
eligible instructions out of a loop. We can use profiles if they are
available.

Ivan