Right now, we have phi placement code in two places and there are other
places where it would be nice to be able to do this analysis. Instead of
repeating it all over the place, this commit adds a helper for placing all
of the needed phi nodes for a value.
v2: Add better documentation
Reviewed-b
On Mon, Mar 21, 2016 at 7:37 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 21, 2016 at 4:21 PM, Connor Abbott wrote:
>>
>> On Mon, Mar 21, 2016 at 6:51 PM, Connor Abbott
>> wrote:
>> > So overall, I think that there needs to be some explanation of the
>> > design choices in the implementation. The
On Mon, Mar 21, 2016 at 4:21 PM, Connor Abbott wrote:
> On Mon, Mar 21, 2016 at 6:51 PM, Connor Abbott
> wrote:
> > So overall, I think that there needs to be some explanation of the
> > design choices in the implementation. The API documentation is great,
> > but digging into the implementation
On Mon, Mar 21, 2016 at 6:51 PM, Connor Abbott wrote:
> So overall, I think that there needs to be some explanation of the
> design choices in the implementation. The API documentation is great,
> but digging into the implementation might be a little daunting without
> knowing e.g. why NEEDS_PHI i
So overall, I think that there needs to be some explanation of the
design choices in the implementation. The API documentation is great,
but digging into the implementation might be a little daunting without
knowing e.g. why NEEDS_PHI is a thing. From what I gather, there are
three potential states
Right now, we have phi placement code in two places and there are other
places where it would be nice to be able to do this analysis. Instead of
repeating it all over the place, this commit adds a helper for placing all
of the needed phi nodes for a value.
---
src/compiler/Makefile.sources |