[PATCH] "float2int": Add a new pass to demote from float to int where possible.

James Molloy james.molloy at arm.com
Thu Feb 26 09:24:42 PST 2015


Hi Philip,

In http://reviews.llvm.org/D7790#129842, @reames wrote:

> I'm going to deref to Hal on the code for the moment.  It sounds like things are still in progress.  Once you've got the approach nailed down, I'll try to take another look for nits.


Thanks!

> At a high level, why are you restricting yourself to entire sequences?  It seems like this would be profitable even if all you did was push the float to int conversion back a bit or the int to float forward a bit.  This might even simplify the code.


The short answer is "first do no harm". I flirted with the idea of doing what you suggest in previous patch incarnations, and had trouble working out when it was profitable.

In the current incarnation, the heuristic is "yes", which simplifies things quite a bit. By converting an entire chain, we:

- Never add any instructions.
- Never move any instructions.

The former might be required if we had to push a cast up past a PHI, and the latter might cause issues if we pushed a cold cast into a hot region. We'd have to be very careful to only move casts outside of loops, never inside, for example (unless we could remove them completely). This means that an iterative,greedy method is really out of the question and a whole-function analysis is required.

I still hope to be able to do what you want, maybe at a (much?) later stage. I hope that the current infrastructure is a good staging point for such a transform - really it's just adding a weighting to each node and a global sum determining if the transform is worth it. The mechanism shouldn't have to change, I think.

> Can this be a range loop? Can you use a utility to delete things which are recursively trivially dead?


In this latest incarnation it's now a trivial loop, so I think using a utility isn't really required. Also, I know which nodes are dead; getting a utility to discover them isn't really required.

It can't be a range loop because I need to reverse-iterate over the container to ensure I hit uses before defs.

Cheers,

James


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7790

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list