From Quentin Carbonneaux to ~mpu/qbe
Hello, I agree that having a dynamic jump functionality may be desirable. However, I do not see how the lack of such jumps is blocking you. On Fri, Feb 24, 2023, at 17:13, Orazov Andrew wrote: > fun serve coro_frame = { > switch coro_frame.index { > case 0: > read(&coro_frame.buf); > coro_frame.index = 1; > return; > case 1:
From Quentin Carbonneaux to ~mpu/qbe
On Mon, Mar 13, 2023, at 00:35, Ember Sawady wrote:
> And another one: https://p.d2evs.net/753120887.txt
I fixed a screwup in the last commit and it appears
to work on master. Sorry for this round-tripping!
From Quentin Carbonneaux to ~mpu/qbe
On Sun, Mar 12, 2023, at 20:04, Ember Sawady wrote:
> https://p.d2evs.net/1139051936.txt
Thanks for reporting. It is fixed in master
by df1f67584a2bb4576710a01504b9172fde199678.
From Quentin Carbonneaux to ~mpu/qbe
LGTM. Applied and pushed.
On Thu, Feb 23, 2023, at 15:10, Alexey Yerin wrote:
> Note sure if T.apple check is really necessary here
I'll check.
From Quentin Carbonneaux to ~mpu/qbe
I just pushed 9632f2f148bf545fea09f25f34a316ec8ae86256 on master. It fixes your repro (added as a new test).
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Feb 24, 2023, at 03:36, Ember Sawady wrote: > Minimal reproduction is https://p.d2evs.net/1274484195.txt, more maximal > reproduction is the Hare standard library breaking with > https://lists.sr.ht/~sircmpwn/hare-dev/patches/38947 applied, which I > minimized to https://p.d2evs.net/4116803701.txt. Great rero. I'm looking at it and I think I understand what's going wrong. One of the stores is dead and is thus treated by the analysis like a no-op; but it is only a no-op *pre-fusing*, not after the slots are fused. We should either kill it entirely or not fuse the slots. I'll think of a fix. Thanks for the neat repro & reporting.
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Mar 10, 2023, at 20:20, Quentin Carbonneaux wrote: > data $array = { w 0, w 1, w 2 } > data $int_ptrs = { > w $array, > w $array+4, > w $array+8 > } I should have picked 'l' as type for the elements of the second array, of course.
From Quentin Carbonneaux to ~mpu/qbe
On Fri, Mar 10, 2023, at 18:19, Ember Sawady wrote:
> Yes, it's the pointer ($foo) that's a constant.
Ember is right. If you want to correct the phrasing
of the IL doc to disambiguate I would be happy to
take your patch in. Otherwise, I'll just have a stab
at it.
I meant to say that global addresses can be used
anywhere a literal constant such as 4 can be used.
For instance you can have:
data $array = { w 0, w 1, w 2 }
data $int_ptrs = {
From Quentin Carbonneaux to ~mpu/qbe
On Wed, Feb 8, 2023, at 16:28, Quentin Carbonneaux wrote:
> I have no strong feelings about all that though.
One thing, though. I'll not take patches that add syntax
for 25 different assemblers. For a specific OS & arch,
I want qbe to target the mainstream local as. Doing
otherwise would create a maintenance burden.
From Quentin Carbonneaux to ~mpu/qbe
On Wed, Feb 8, 2023, at 10:19, Drew DeVault wrote: > Maybe we can add another qbe flag (ala -t) which configures the target > assembly dialect? We'll need to do that eventually to add Plan 9 support > for instance. There used to be a flag for doing that. I killed it and kept -t only. The advantage of having -t only is that we don't have to check that the combination selected makes sense. For Plan 9 support, I'd think we can just add targets (e.g., amd64_plan9). I have no strong feelings about all that though.