Date: Fri, 02 Oct 2015 10:40:04 -0700
From: Gerolf Hoflehner via llvm-dev <llvm-dev@lists.llvm.org>
To: Sanjay Patel <spatel@rotateright.com>
Cc: "spatel+llvm@rotateright.com" <spatel+llvm@rotateright.com>,
llvm-dev <llvm-dev@lists.llvm.org>, Haicheng Wu
<haicheng@codeaurora.com>
Subject: Re: [llvm-dev] Register Spill Caused by the Reassociation
pass
Message-ID: <DE90E812-306F-4D8D-9D9F-D92AAF9A29EE@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