This is an archive of the discontinued LLVM Phabricator instance.

[ValueTracking] define/use max recursion depth in header
ClosedPublic

Authored by spatel on Aug 17 2020, 2:53 PM.

Details

Summary

There's a potential motivating case to increase this limit in PR47191:
http://bugs.llvm.org/PR47191

But first we should make it less hacky. The limit in InstCombine is directly tied to this value because an increase there can cause asserts in the underlying value tracking calls if not changed together. The usage in VectorUtils is independent, but the comment suggests that we should use the same value unless there's a known reason to diverge. There are similar limits in codegen analysis, but I think we should leave those independent in case we intentionally want the optimization power/cost to be different there.

Diff Detail

Event Timeline

spatel created this revision.Aug 17 2020, 2:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2020, 2:53 PM
spatel requested review of this revision.Aug 17 2020, 2:53 PM

Even though it is constexpr, you most likely want to also define it in ValueTracking.cpp TU,
i remember having pretty fun linking issues with cases like this.

Even though it is constexpr, you most likely want to also define it in ValueTracking.cpp TU,
i remember having pretty fun linking issues with cases like this.

Ok - I was afraid of something like that. Is there an example of the recommended way to spell this already in LLVM somewhere?
I saw that UndefMaskElem was done similarly to this (only in a header file), so that's why I figured it was worth a try.

Even though it is constexpr, you most likely want to also define it in ValueTracking.cpp TU,
i remember having pretty fun linking issues with cases like this.

Ok - I was afraid of something like that. Is there an example of the recommended way to spell this already in LLVM somewhere?
I saw that UndefMaskElem was done similarly to this (only in a header file), so that's why I figured it was worth a try.

You're probably ok. The linker error is likely only to happen if you do something that takes the address of the global. Like passing it to a function that takes a "unsigned &".

Even though it is constexpr, you most likely want to also define it in ValueTracking.cpp TU,
i remember having pretty fun linking issues with cases like this.

Ok - I was afraid of something like that. Is there an example of the recommended way to spell this already in LLVM somewhere?
I saw that UndefMaskElem was done similarly to this (only in a header file), so that's why I figured it was worth a try.

You're probably ok. The linker error is likely only to happen if you do something that takes the address of the global. Like passing it to a function that takes a "unsigned &".

Thanks. If there's some way to enforce that constraint, let me know. Otherwise, this is ok as-is?

nikic accepted this revision.Aug 18 2020, 1:07 PM

LGTM

It seems unlikely that this constant will be odr-used.

This revision is now accepted and ready to land.Aug 18 2020, 1:07 PM
This revision was automatically updated to reflect the committed changes.