Displaying 4 results from an estimated 4 matches for "r173320".
2013 May 07
2
[LLVMdev] #APP/#NOAPP
...e only one who thinks this. What's so
> complicated about doing this either at selection dag or MI lowering
> time?
>
> -eric
An earlier part of this I actually did do with selection DAG and it was
messy and the code was much less easy to understand than this Module IR
pass is.
r173320
I intend to move most of this code into the new pass at a later time. It
will make it possible
to understand the whole scheme in one place.
Much of the code needs to access the IR anyway, even though it finds it
starting with the
DAG.
>>> I hope you don't mind if I play devil'...
2013 May 09
0
[LLVMdev] #APP/#NOAPP
...>> complicated about doing this either at selection dag or MI lowering
>> time?
>>
>> -eric
>
> An earlier part of this I actually did do with selection DAG and it was
> messy and the code was much less easy to understand than this Module IR pass
> is.
>
> r173320
>
> I intend to move most of this code into the new pass at a later time. It
> will make it possible
> to understand the whole scheme in one place.
>
> Much of the code needs to access the IR anyway, even though it finds it
> starting with the
> DAG.
>
>
>
>>&...
2013 May 06
0
[LLVMdev] #APP/#NOAPP
On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote:
> Hi Hal,
>
>
> I think that it's perfectly valid to generate inline assembler and it
> looks 1000 times cleaner than if I tried to do this same work with
> selection DAG.
>
I'm pretty sure you're the only one who thinks this. What's so
complicated about doing this either at
2013 May 06
3
[LLVMdev] #APP/#NOAPP
Hi Hal,
I think that it's perfectly valid to generate inline assembler and it
looks 1000 times cleaner than if I tried to do this same work with
selection DAG.
> I hope you don't mind if I play devil's advocate here...
>
> Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of