[PATCH] D60133: [DAGCombiner] Improve detection of unmergable stores, based on type size (WIP)

[Nirav via llvm-commits]

The current interfaces definitely do not provide anything like that. As I
recall, most of the use cases requiring canMergeStoresTo involve ad hoc
ways to locally declare a type/operation invalid localized to the specific
target, so I suggest the just marginally expanding hte interface to capture
the one issue we've seen so far (no-implict-float) and defer any deeper
analysis for when we run into it.

On Fri, May 3, 2019, 11:50 Florian Hahn via Phabricator <
reviews at reviews.llvm.org> wrote:

> fhahn added a comment.
>
> In D60133#1452430 <https://reviews.llvm.org/D60133#1452430>, @niravd
> wrote:
>
> > It's not sufficient to check if you can merge two stores into a valid
> node; there are backends where you need 4 or more to get a legal merged
> store.
> >
> > If you look at target-specific implementations of CanMergeStoresTo it
> essentially serves as a context-specific find maximum store which is what
> we need here.  If you massage that interface a bit you can fold most of
> this check in there.
>
>
> Sorry for the long delay with getting back to this one! I had a look at
> the X86 and AArch64 implementations of CanMergeStoresTo and it looks like
> they are not too helpful with getting a reasonable upper bound. They return
> true for functions without noimplicitfloat and otherwise limit the size to
> 64 bits or 32 bits for X86 32 bit mode. I think one thing that's more
> important to check is whether the merged type is legal for the target. This
> will weed out stores with types too large for the target.
>
> So I think we need to do more work than just checking canMergeStoresTo
> unfortunately. What we would need is the maximum size for integer, float
> and vector stores I think, but I am not sure if any existing interface
> provides that info.
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D60133/new/
>
> https://reviews.llvm.org/D60133
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190506/bfcb1465/attachment-0001.html>