[LLVMdev] Moving towards a singular pointer type

Chandler Carruth chandlerc at gmail.com
Tue Feb 17 13:58:50 PST 2015


On Tue, Feb 17, 2015 at 1:35 PM, David Blaikie <dblaikie at gmail.com> wrote:

> You could say with more certainty, but I see this as an incremental way to
>> move towards the singular pointer type model.  I suspect that there will be
>> *some* impact on the optimizer, but that the optimizer can be taught how to
>> handle it.
>>
>> If you go through the effort to build a huge patch that switches the
>> universe over to a singular pointer type, you won’t be able to land it
>> until the optimizer regressions are fixed.  This could be a very long time
>> maintaining a large patch out of tree (never fun).
>>
>
> Yeah, possibly - chatted about this a bit with Chandler too & his
> experience has been that shaking these sort of things out is often
> out-of-tree (granted, that's with small changes to the canonicalization of
> pointer types in specific places - this kind of widescale change might hit
> quite a few tests in-tree first before reaching the long-tail of random
> out-of-tree tests people run/care about) so having an out-of-tree patch
> won't necessarily get us far, and as you say - comes at a bit of a cost to
> maintain it out of tree and then transform it into the final version later
> once we introduce a true opaque pointer type.
>

To clarify, I have consistently found almost all of the optimizer
regressions due to in tree tests and relatively easily. There were just
some small number of long-tail problems that were only really exposed by
flipping the switch and shaking out the regressions.

I'm not actually worried about this change though Chris, at least w.r.t.
optimizer changes being necessary. There are a few reasons:

1) The old ScalarRepl pass cared a *lot* about pointer type, but the new
SROA doesn't care at all, so the biggest offender is essentially handled.

2) We've recently changed our pointer canonicalization rules several times
and in different ways. Each of those changes helped shake out bugs where
the optimizer was relying on the pointer type for something. The number of
things found has dropped dramatically with each change, so I don't think
there is a huge pile of problems left hiding somewhere.

3) Almost all of the problems we found with the changes to canonicalization
were actually cases where *casts* impeded optimizations, not the different
pointer type. This change will be a strict reduction in the need for casts,
and thus I expect it to actually be safer than the other changes. All
evidence is that most of the remaining reliance on these kinds of things
are actually relying on an absence of casts. With this change, the casts
will all go away.


So, I'm not as worried about having a very drawn out period of fixing the
optimizer. I think we'll probably uncover a few minor things that we have
to fix immediately, and then when we make the change some small number of
benchmarks will regress (likely on some small number of platforms). We'll
have to track those down, no doubt, but I'm not worried about it preventing
progress for a long time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/37299f30/attachment.html>


More information about the llvm-dev mailing list