search for: looppr

...e original loop looks like? No, not really, the reduced one just shows the difference between gcc and clang. There were some variations to this, but I chose this since it gave a very small output. Sorry if it was confusing. > > If so, then yes, this is probably a case where the aggressive LoopPRE > mentioned in the other thread that Eli linked to would be useful.  > Once we'd done the PRE, then everything else should collapse. Thanks for the link, it's good to know this issue is recognized. If I understand it correctly, the reason clang is storing in each iteration is due...

...lines with little problem. One way of looking at this load specific transform is as an extreme form of PRE (partial redundancy elimination). Our current PRE implementation doesn't handle cases this complicated. It occurred to my later that simply framing the new transform as a separate pass (LoopPRE) and using the same AST + SSA construction approach would be straight forward. So, if folks think that having an aggressive form of load PRE in LICM is going a bit too far, it'd be easy to represent as an optional separate pass. I'd still prefer having LICM contain the logic though. Th...

Hi, I have a benchmark (mcf) that is currently slower when compiled with clang compared to gcc 8 (~10%). It seems that a hot loop has a few differences, where one interesting one is that while clang stores an incremented value in each iteration, gcc waits and just stores the final value just once after the loop. The value is a global variable. I wonder if this is something clang does not do

...; One way of looking at this load specific transform is as an > extreme form of PRE (partial redundancy elimination). Our current > PRE implementation doesn't handle cases this complicated. > It occurred to my later that simply framing the new transform as a separate pass (LoopPRE) and using the same AST + SSA construction approach would be straight forward.  So, if folks think that having an aggressive form of load PRE in LICM is going a bit too far, it'd be easy to represent as an optional separate pass.  I'd still prefer having LICM contain the logic though....

...oad specific transform is as an extreme form >>> of PRE (partial redundancy elimination). Our current PRE implementation >>> doesn't handle cases this complicated. >>> >> It occurred to my later that simply framing the new transform as a >> separate pass (LoopPRE) and using the same AST + SSA construction approach >> would be straight forward. So, if folks think that having an aggressive >> form of load PRE in LICM is going a bit too far, it'd be easy to represent >> as an optional separate pass. I'd still prefer having LICM con...

I'm thinking about making some semi radical changes to load store promotion works in LICM, and figured it would be a good idea to get buy in before I actually started writing code.  :) TLDR: legality of sinking stores to exits is hard, can we separate load handling into a super aggressive form of PRE, and use predicated stores to avoid solving legality question? Background We've