<div dir="ltr">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. </div><div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019, 11:50 Florian Hahn via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">fhahn added a comment.<br>
<br>
In D60133#1452430 <<a href="https://reviews.llvm.org/D60133#1452430" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D60133#1452430</a>>, @niravd wrote:<br>
<br>
> 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.<br>
><br>
> 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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D60133/new/" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D60133/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D60133" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D60133</a><br>
<br>
<br>
<br>
</blockquote></div>