[llvm-dev] About LoopDeletion and infinite loops ... again! (RFC?)

Marcello Maggioni via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 2 01:25:41 PDT 2017



> On Sep 29, 2017, at 9:34 PM, Davide Italiano <davide at freebsd.org> wrote:
> 
> On Fri, Sep 29, 2017 at 8:02 PM, Marcello Maggioni <mmaggioni at apple.com> wrote:
>> I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?)
>> 
> 
> That could be a reason, but it wasn't my main motivation. Basically
> I'm worried about having per-passes specific flags for non-debug
> purposes.
> Also, whether it's valid to perform some optimizations is something
> that the source language rules should dictate, not something the user
> should control. Exposing such flag is dangerous as people could just
> add `-mllvm -remove-my-loops` with any frontend and then complain the
> semantic of their code is not preserving. In some sense they are
> shooting themselves in the foot, but I'm under the impression that
> flags shouldn't really change the semantic (although some do, e.g.
> -ffast-math, which many regret).

Yeah, I totally understand your point and is valid. Considering the work that is being done in the other patch it totally makes sense to wait for that to be done and then “fix” LoopDeletion to allow
non-sideeffected infinite loops to be removed … unless some other issues arise with that.

Thanks,
Marcello

> 
>> BTW if the other proposal passes can we basically assume that if a loop doesn’t have the sideeffect intrinsic in it is then removable?
>> 
> 
> The patch as far as I can tell blocks some optimizations in presence
> of the intrinsic. The intrinsic itself doesn't really lower to
> anything, as far as I can tell. I'm not sure the semantic has settled
> down (and I still need to digest the whole proposal).
> 
>> That patch seems to suggest that in its current state llvm is mostly broken for languages that consider all infinite loops as unremovable ... (but I didn’t read all the discussion)
>> 
> 
> I think at least Rust (and maybe Java? but don't quote me on that) are broken.
> https://github.com/rust-lang/rust/issues/42009
> The original bugzilla for this issue has 3 digits which says a lot
> about how old the problem is :)
> https://bugs.llvm.org//show_bug.cgi?id=965
> 
> Thanks,
> 
> --
> Davide



More information about the llvm-dev mailing list