llvm dev - Apr 2016 - GVN pass limitation.

Cases like this illustrate why we should avoid arbitrary cutoffs in 
analysis passes if at all possible.

Philip

On 04/18/2016 03:08 AM, Joerg Sonnenberger via llvm-dev
wrote:
> On Mon, Apr 18, 2016 at 05:17:04PM +0800, xiuli pan via llvm-dev wrote:
>> So if there is another way to pass this memdep-block-scan-limit into
the
>> pass manager or context? Or how could I set this
memdep-block-scan-limit
>> right with libclang and libllvm?
> Can't you call llvm::cl::ParseCommandLineOptions once at startup of
your
> program? The internal flags are sticky, they are not a per-compilation
> property.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Mon, Apr 18, 2016 at 04:37:58PM -0700, Philip Reames
wrote:
> Cases like this illustrate why we should avoid arbitrary cutoffs in
analysis
> passes if at all possible.
I fully agree on that, but it doesn't help if super-linear behavior,
both in terms of CPU time and memory use practically happen. It doesn't
mean that we couldn't e.g. tune the limits based on the optimisation
level, but currently it is kind of all or nothing.

Joerg

Necessary super-linear behavior in analysis is pretty rare.
When it does occur, it should mostly be occurring on strange and wonderful
CFGs.

IE andersen's is N^3. You are highly unlikely to find *any* real world
cases that trigger N^3 behavior out of the andersen's implementation in GCC.

Honestly, at the point where you've added more than 1-2 knobs to something,
it's time to reconsider whether that's the best way to do it anymore.


On Tue, Apr 19, 2016 at 6:19 AM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Apr 18, 2016 at 04:37:58PM -0700, Philip Reames wrote:
> > Cases like this illustrate why we should avoid arbitrary cutoffs in
> analysis
> > passes if at all possible.
>
> I fully agree on that, but it doesn't help if super-linear behavior,
> both in terms of CPU time and memory use practically happen. It doesn't
> mean that we couldn't e.g. tune the limits based on the optimisation
> level, but currently it is kind of all or nothing.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160419/12e87355/attachment.html>