[PATCH] D73131: [IR] Value::getPointerAlignment(): handle pointer constants
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Feb 8 12:25:01 PST 2020
lebedev.ri added reviewers: spatel, nikic.
lebedev.ri added a comment.
In D73131#1861998 <https://reviews.llvm.org/D73131#1861998>, @jdoerfert wrote:
> In D73131#1861978 <https://reviews.llvm.org/D73131#1861978>, @lebedev.ri wrote:
>
> > In D73131#1861781 <https://reviews.llvm.org/D73131#1861781>, @jdoerfert wrote:
> >
> > > In D73131#1861624 <https://reviews.llvm.org/D73131#1861624>, @mlychkov wrote:
> > >
> > > > In D73131#1861595 <https://reviews.llvm.org/D73131#1861595>, @mlychkov wrote:
> > > >
> > > > > ...
> > > > > Is this alignment accounting intended to be used for getelementptr instructions too?
> > > > > If yes then may we cleanup extra user after we get TrailingZeros value?
> > > >
> > > >
> > > > Or is there a way to perform this computation without const_cast?
> > >
> > >
> > > The problem is `ConstantExpr::getPtrToInt`. Do we striclty need that?
> >
> >
> > That is the workhorse here, we can't get around using it.
> >
> > Without seeing the code where this is causing trouble i'm somewhat unsure
> > on how this is a problem, or how to test that the fix would actually fix it.
> > Perhaps, after computing `TrailingZeros`, we need to explicitly DCE `CstInt`?
>
>
> That'll probably work as well. If `CstInt` has 0 users it can be removed.
Do we have an established precedent on this kind of issues?
I don't recall ever seeing such a problem before,
nor do i recall seeing manual cleaning up of tmp constantexprs.
I'm mainly wondering whether we actually have such guarantees that this violated (should not create new users)?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D73131/new/
https://reviews.llvm.org/D73131
More information about the llvm-commits
mailing list