This is the mail archive of the gcc@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: [PATCH] Improved target tuning in simplify-rtx.c


[ Redirected to gcc ]

Roger Sayle <roger@eyesopen.com> writes:

> The following patch makes use of the backend's rtx_cost function when
> deciding whether or not to apply transformations in simplify-rtx.c.

One of the problem I have when dealing with TARGET_RTX_COSTS is that
it is hard to know what to measure.  Returning the number of
instructions clearly isn't right (unless optimizing for size), but
returning the number of cycles can also be misleading, since there are
instruction cache advantages to using fewer instructions.  So you win
up tweaking the code heuristically, when makes me uncomfortable, and
could lead to making poor decisions as the compiler changes.

When looking at Roger's patch here, though, I realized that surely
some significant number of uses of TARGET_RTX_COSTS is simply to judge
the relative costs of two different pieces of code.  Suppose that,
rather than coming up heuristics which cause the compiler to make the
right decision when comparing, we just provide a target hook which
directly compares two pieces of code and tells the compiler which one
is preferred.  It could even be a -1,0,1 type of result.

We could get there incrementally, since the default implementation
would just call the existing TARGET_RTX_COSTS.

We could have a separate version when using optimize_size, instead of
overloading a single function which really needs to behave quite
differently in that case.

Does this seem like a good idea to remove some of the guesswork
involved in creating TARGET_RTX_COSTS?

Ian


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