[llvm-dev] Splitting 'expand' into 'split' and `expand`.

[Dylan McKay via llvm-dev]

I plan on refactoring LegalizeIntegerTypes.cpp to make it more readable and
less modular. After this I will submit a patch which adds a Split
legalization action which always expands by splitting, and leaving Expand
with its current meaning and not breaking any existing code. I believe it
would be much more meaningful talking about this change with a prototype.
​

On Thu, Aug 13, 2015 at 8:41 PM, Dylan McKay <dylanmckay34 at gmail.com> wrote:

> It’s faked by saying 64-bit add is legal and the expand to add + carry is
> handled during instruction selection, which works and also makes addressing
> mode matching easier.
>
> This is basically what we do currently. So this proposal (or at least
> something similar) would also help the AMDGPU backend?
> ​
>
> On Thu, Aug 13, 2015 at 4:21 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
>
>>
>> On Aug 12, 2015, at 8:36 PM, Dylan McKay <dylanmckay34 at gmail.com> wrote:
>>
>>
>>    - 16-bit addition is illegal, should expand into an add and an add
>>    with carry
>>    - A few operations support 16-bit operands - the 16-bit DREGS register
>>    class
>>
>> This sounds like basically the same situation AMDGPU has with 64-bit
>> integers. Since you have a 16-bit register class, you avoid terrible
>> problems by not having i16 be a legal type. There is no 64-bit add, and
>> needs to be expanded into 32-bit add + carry. There are fewer 64-bit
>> operations available, but some are. It’s faked by saying 64-bit add is
>> legal and the expand to add + carry is handled during instruction
>> selection, which works and also makes addressing mode matching easier.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150815/0a628913/attachment.html>