search for: sliceupillegalintegerphi

Hi, I am working to improve SROA to generate better code when a method has a struct in its arguments. I would appreciate it if I could have any suggestions or comments on how I can best proceed with this optimization. * Problem * I observed that LLVM often generates redundant instructions around glibc’s istreambuf_iterator. The problem comes from the scalar replacement (SROA) for methods with an

...legalization of types in selection DAG split the 64-bits loads. >> >> Should we do something similar for 64-bits targets with the proper target >> hooks? >> If yes, what hooks? > > Hmm... detecting the pattern in IR isn't particularly hard; see > InstCombiner::SliceUpIllegalIntegerPHI for an example of code which > detects a similar sort of pattern. You might want to consider adding > something in instcombine. Thanks for the direction, I will have a look. > > I'm trying to think if there's some scenario where you wouldn't want > to rewrite the load...

...ot suffer this because the > legalization of types in selection DAG split the 64-bits loads. > > Should we do something similar for 64-bits targets with the proper target > hooks? > If yes, what hooks? Hmm... detecting the pattern in IR isn't particularly hard; see InstCombiner::SliceUpIllegalIntegerPHI for an example of code which detects a similar sort of pattern. You might want to consider adding something in instcombine. I'm trying to think if there's some scenario where you wouldn't want to rewrite the load into two loads, but I'm having trouble coming up with anything: two...

...use the > legalization of types in selection DAG split the 64-bits loads. > > Should we do something similar for 64-bits targets with the proper target > hooks? > If yes, what hooks? > > > Hmm... detecting the pattern in IR isn't particularly hard; see > InstCombiner::SliceUpIllegalIntegerPHI for an example of code which > detects a similar sort of pattern. You might want to consider adding > something in instcombine. > > Thanks for the direction, I will have a look. > > > I'm trying to think if there's some scenario where you wouldn't want > to rewr...

Hi, I am investigating a poor code generation on x86-64 involving a 64-bits structure with two 32-bits fields (in the attached examples float, but similar behavior is exposed with i32, and we can probably generalize that to smaller types too). The root cause of the problem is in SROA, although I am not sure we should fix something there. That is why I need your advices. ** Problem ** 64-bits

Hi, While comparing the code by LLVM and GCC for some major libraries, I found that LLVM fails to apply jump threading with a method whose return type is std::pair<int, bool> (actually, any pair of 32-bit values like std::pair<bool, int> and std::pair<int, int>). For example, jump threading does not work for the if statement in func. std::pair<int, bool> callee(int v) {

On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry <dmitry.mikulin at sony.com> wrote: > >>> Is this a run with debug info? i.e. are you passing -g to the per-TU >>> pipeline? I'm inclined to think this is mostly an additive effect >>> adding matchers here and there that don't really hurt small testcases >>> but we pay the debt over time (in