# Auto-generate the memory folding tables

**URL:** <https://discourse.llvm.org/t/auto-generate-the-memory-folding-tables/61100>\
**Category:** X86\
**Created:** [March 21, 2022, 5:07am UTC](https://discourse.llvm.org/t/auto-generate-the-memory-folding-tables/61100 "2022-03-21T05:07:02Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![topperc](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/topperc/32/1293_2.png) [@topperc](https://discourse.llvm.org/u/topperc)\
**Post date:** [October 12, 2022, 7:01am UTC](https://discourse.llvm.org/t/auto-generate-the-memory-folding-tables/61100/19 "2022-10-12T07:01:15Z")

</div>

It might not have ever had TB\_NO\_REVERSE in the table. I might have only used it as a guide and decided it needed TB\_NO\_REVERSE. There’s no reason to unfold it anyway. It’s only source is a pointer. One of the uses of unfolding is LICM, but the whole instruction could be hoisted without unfolding.

I think TB\_NO\_REVERSE is needed for the masked forms. The unfolding code won’t create a masked load. It would create a plain load and a masked VEXPANDPDZrrk. That would load elements that should be masked off.

Though that applies to every masked instruction in the unfold table and we don’t have TB\_NO\_REVERSE on them. I think maybe that’s not an issue because we never fold masked load intrinsics into masked arithmetic. So they always start as a whole register load which makes unfolding ok.

That’s not true for expand since we have masked expand load intrinsics.

> PLS: i have a small question, why we do not allow unfolding if the register’s size is greater than the memory’s operand size?

If I remember right, the unfolded load size will be based on the register size. If that’s bigger than the memory operand size, the unfolded load will load more memory and potentially cause a memory fault.

---

_[View the full topic](https://discourse.llvm.org/t/auto-generate-the-memory-folding-tables/61100)._