[LLVMdev] Two new 'llvmnotes'
Christopher Lamb
christopher.lamb at gmail.com
Sun Apr 27 15:21:54 PDT 2008
On Apr 27, 2008, at 2:59 PM, Gordon Henriksen wrote:
> On 2008-04-27, at 15:56, Chris Lattner wrote:
>
>> On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote:
>>
>>> Chris Lattner wrote:
>>>
>>>> On Apr 27, 2008, at 10:58 AM, Talin wrote:
>>>>
>>>>> I would certainly make use of this in my frontend.
>>>>>
>>>>> I suggest the names "getfield" and "setfield" for the two
>>>>> operations,
>>>>
>>>> I agree that 'get/insertvalue' are pretty generic, and am welcome
>>>> to suggestions. Get/set *field* imply that this applies only to
>>>> structs, but it also works with arrays. I would actually prefer
>>>> get/insert *element* but insertelement is already taken.
>>>
>>> What's wrong with using insert/extractelement for arrays and
>>> structs as well as vectors? They're all sequence types.
>>
>> Vector insert/extract element take (potentially variable) Value*'s
>> for the index and only allows one index. Aggregate get/set take
>> constants and are variadic.
>
> Forbidding variable indices for arrays would seem to rather reduce
> their utility (precisely to that of a homogenous struct). Granted,
> lowering makes updating an indexed value much uglier, but it would
> seem to be an already-solved problem for vector lowering. Is it
> completely impractical to use the same rule as GEP?
I'm not exactly sure what variable indices would mean for an array.
It's not in memory, so you can't get an address of the element (or
else you could just use GEP). Imagine a small array (say two
elements) in registers. Most ISAs don't allow dynamic register
indexing, so I don't think that there is much utility to be lost by
not supporting dynamic indices. OTOH, having the array in registers
isn't gonna fly if you need to index it in a dynamic way anyhow.
--
Christopher Lamb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080427/fd6ab233/attachment.html>
More information about the llvm-dev
mailing list