Displaying 5 results from an estimated 5 matches for "webasm".
2015 Dec 10
2
Allowing virtual registers after register allocation
...ously related to finiteness). Having virtual registers after RA
> >sounds like a huge hack.
>
> I definitely agree that having virtual regs after RA sounds like a
> hack.
>
> But I also don't know why it would be desirable to introduce infinite
> register classes. The WebAsm folks are already saying that they
> would like to do register allocation to target a fixed/limited
> number (might be large though) of "virtual registers". So, instead
> of calling these virtual registers, why not call them physical
> registers, and have a fixed number of th...
2015 Dec 10
3
Allowing virtual registers after register allocation
...gt; >sounds like a huge hack.
> >>
> >> I definitely agree that having virtual regs after RA sounds like a
> >> hack.
> >>
> >> But I also don't know why it would be desirable to introduce
> >> infinite
> >> register classes. The WebAsm folks are already saying that they
> >> would like to do register allocation to target a fixed/limited
> >> number (might be large though) of "virtual registers". So,
> >> instead
> >> of calling these virtual registers, why not call them physical
>...
2015 Dec 10
2
Allowing virtual registers after register allocation
On 12/10/2015 11:39 AM, Hal Finkel via llvm-dev wrote:
>
> But there is lots of code that assumes that it can iterate over all physical registers in some class. My thought had been that you don't want to introduce infinite physical register sets because this assumption of enumerability is broken (as is the assumption that the size does not dynamically change). Thoughts?
The post-RA code
2015 Dec 10
3
Allowing virtual registers after register allocation
...via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> > Whether it’s a hack or not depends on the sizes in question. Existing
> > X86 already has this property for 64 bit, there are registers which
> > simply don't exist
> > unless the target arch is 64 bit. If WebASM folks are thinking of
> > allocating down to something like 32 or 64 registers, with maybe a
> > maximum of 128 or 256, then
> > making some portion of this reserved when a tighter allocation (only
> > coloring to 16 or 32) seems completely doable (and natural) using
> &g...
2016 Aug 26
3
[RFC] AAP Backend
Re-reading the thread, it looks like there is a difference of opinion
what "an active community behind the target" means: an active community
of LLVM-target-maintainers, and/or an active community of end-users.
I'd think the immediate practical concern is that there is an active
community of LLVM-target-maintainers, so that the maintenance burden
does not fall unduly on the rest of