Remove trivial branches in with_cond

[Aatch]

Removes branches on constant values when using with_cond, improving the
performance of non-optimized code and (hopefully) improving compile times.

This is a fairly simple front-end optimization.

@cmr if you could see if there is a measurable difference in compile times, that would be awesome

[emberian]

My setup right now doesn't usually provide reliable measures of time, but I can try (in a few hours)

[alexcrichton]

Do you have any statistics for before/after codegen for this? Front-end optimizations are tricky and can easily go wrong, so it's good to make sure that they're worth it before committing.

[Aatch]

@alexcrichton for what it's worth, we do a similar optimization in controlflow::trans_if.

[alexcrichton]

Indeed, and it has caused bugs before (see #9484). That was also a proven win because all of our debug! calls could predominately be optimized out in the frontend with --cfg ndebug.

[dotdash]

FWIW, in librustc.no-opt.ll we have these:

      1   br i1 false, label %cond17, label %next16
      1   br i1 false, label %cond19, label %next18
      1   br i1 false, label %cond22, label %next21
      1   br i1 false, label %cond25, label %next24
      1   br i1 false, label %cond28, label %next27
      2   br i1 false, label %cond2, label %next1
      2   br i1 false, label %cond3, label %next2
      1   br i1 false, label %cond44, label %next43
      1   br i1 false, label %cond4, label %next3
     18   br i1 false, label %cond, label %next

And the %cond* blocks are always just a single call or invoke followed by unreachable. So probably not a huge win.

[alexcrichton]

@dotdash, is that saying that out of all of rustc there are only 29 constant branches? If so, this frontend optimization may not be worth it at this time.

[dotdash]

@alexcrichton The above is the output from grep 'br i1 [^%]' librustc.no-opt.ll | sort | uniq -c | grep cond, so 29 constant branches that originate from with_cond. There are a few hundred that originate from || or &&.

[dotdash]

Correction, they don't directly originate from && or || in the code(at least most of them don't), but from #[deriving(Eq)].

[huonw]

It would be possible (although annoying) to make the implementation of deriving(Eq) less neat by avoiding doing a straight fold, and so removing the base cases false || ... and true && ... from the output, if it's considered to be a large problem.

[dotdash]

@huonw, I don't think it's worth the trouble. Better have the shortcut in trans_lazy_binop then. But I doubt that that makes much of a difference either.

[alexcrichton]

While a plausible optimization, it sounds like we don't generate code that benefits much from this, so I'm going to close this for now.

We may want to implement this in the future, but it's likely more reliable to wait for a visible benefit in order to exercise the optimization.