[IRBuilder] Add getByteTy and use it in CreatePtrAdd

[s-barannikov]

The change requires DataLayout instance to be available, which, in turn,
requires insertion point to be set. In-tree tests detected only one case
when the function was called without setting an insertion point, it was
changed to create a constant expression directly.

[s-barannikov]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [SimplifyLibCalls] Add initial support for non-8-bit bytes #106542
• [ValueTracking] Add CharWidth argument to getConstantStringInfo (NFC) #106541
• [IR] Account for byte width in m_PtrAdd #106540
• [IRBuilder] Add getByteTy and use it in CreatePtrAdd #106539 👈 (View in Graphite)
• [ValueTracking] Make isBytewiseValue byte width agnostic #106538
• [IR] Make @llvm.memset prototype byte width dependent #106537
• [DataLayout] Add byte specification #106536
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[nikic]

For this and #106540, I'm not convinced that we should actually make the canonical i8 type for ptradd byte width dependent. The only thing that matters is that the used type has an alloc size of one byte, so always using i8 should be fine.

I'd rather have the question "is this GEP a ptradd" be answerable without DL.

[s-barannikov]

For this and #106540, I'm not convinced that we should actually make the canonical i8 type for ptradd byte width dependent. The only thing that matters is that the used type has an alloc size of one byte, so always using i8 should be fine.

Indeed, it is the type alloc size that matters most.
Sometimes, however, i8 geps lead to incorrect transformations or other unfortunate effects like infinite loops. In particular, this happens when geps are canonicalized: we check if the gep is a canonical, and if not, rewrite it to the canonical one, which is currently i8. Here is an example. We're changing i32 gep to i8 gep and multiplying the index by 4. With 32-bit bytes this transformation is incorrect because the canonical gep is i32 one, not i8.

I'd rather have the question "is this GEP a ptradd" be answerable without DL.

I'd like it too. I imagine the issue will resolve itself once we have ptradd as a first class instruction in LLVM IR rather than a gep pattern.