Displaying 3 results from an estimated 3 matches for "rl296252".
2017 Feb 25
2
rL296252 Made large integer operation codegen significantly worse.
Hi,
I'm working with workload where the bottleneck is cryptographic signature
checks. Or, in compiler terms, most large integer operations.
Looking at rL296252 , the state of affair in that area degraded quite
significantly, see test/CodeGen/X86/i256-add.ll for instance.
Is there some kind of work in progress here and it is expected to get
better ? Because if not, that's a big problem. It looks like the problem is
that the compiler now choose to use...
2017 Feb 28
2
rL296252 Made large integer operation codegen significantly worse.
...ister of eflags and mark the various carry-in ops as only
using that. Might be worthwhile doing that, separately, even if fixing #1
makes this particular issue disappear for this test case.
On Sat, Feb 25, 2017 at 3:06 PM, Nirav Davé via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> rL296252's main change was to turn on anti-aliasing in the DAGCombiner.
> This should generally be a mild improvement to code due to the relaxed
> memory constraints, modulo any patterns downstream that are no longer
> general enough. This looks to be the case here.
>
> I'm going to...
2017 Feb 28
2
rL296252 Made large integer operation codegen significantly worse.
I see we're missing an isel pattern for add producing carry and doing a
memory RMW. I'm going to see if adding that helps anything.
~Craig
On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Yes. I'm seeing that as well. Not clear what's going on.
>
> In any case it looks to be unrelated to the alias analysis so barring