aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAgeFilesLines
* revert cbf1018b21e and actual fixlemon2026-04-141-3/+10
| | | | | Actually that check was OK. The issue was in isnullpo(), not detecting the folded `(void*)0`
* c: allow nested aggregate with flexible array memberlemon2026-04-141-2/+4
|
* c: fix type of `<unsigned> /= <float>`lemon2026-04-141-2/+5
| | | | | | Would wrongly generate `udiv` and fail later in the backend. Should add a IR sanity checks pass to catch e.g. unsigned operations being used with floating point classes.
* backend: allow zero-size stack allocationslemon2026-04-141-1/+1
| | | | Hm.
* c: make type of conditional expr with pointers match non void pointerlemon2026-04-141-1/+1
| | | | | | | | | | | | | | | | Here's what the C standard[1] says about the conditional operator: ``` if one operand is a null pointer constant, the result has the type of the other operand; otherwise, one operand is a pointer to void or a qualified version of void, in which case the result type is a pointer to an appropriately qualified version of void. `` But actually, some codebases rely on things like 'x ? &foo.memb : NULL' to have the type of `&foo.memb`, and not `void *`... [1]: ISO/IEC 9899:TC3 §6.5.15
* cpp: concat 123 ## .lemon2026-04-143-6/+21
|
* update todo.txtlemon2026-04-141-1/+1
|
* c: implement explicit cast complex -> scalarlemon2026-04-131-3/+7
|
* c: match class, not typetag, for libgcc stubslemon2026-04-131-1/+1
|
* Update README.mdlsof2026-04-131-1/+1
|
* C99 complex types MVPlemon2026-04-1314-74/+530
| | | | | | | | | Missing: static eval of complex values, Silly inefficient implementation of equality comparisons between them The whole thing is pretty inefficient without proper aggregate mem2reg anyway
* ir: remove unused field MCTarg.bprlemon2026-04-133-4/+1
|
* frontend: accept zero size arrays and empty aggregateslemon2026-04-134-31/+67
| | | | | | GNU extension. Previously was overloading arraylength==0 to mean unsized array, now they are distinct with the type flag TFUNKNOWN marking unsized arrays & aggregates.
* test/csmith.sh: remove hardcoded memory limitlemon2026-04-121-1/+1
| | | | This was a temporary workaround before d40371b615
* get rid of other warningslemon2026-04-122-5/+4
|
* ir_simpl: remove unused variablelemon2026-04-121-3/+2
|
* aarch64: align leaf func stacks toolemon2026-04-121-2/+2
|
* aarch64: fix stack frame layout, againlemon2026-04-122-35/+37
| | | | | Turns out hardware enforces SP 16-bit alignment in every SP relative load/store, but QEMU doesn't emulate this.
* test/csmith.sh: add --no-packed-structlemon2026-04-111-1/+1
| | | | We don't support #pragma pack yet
* frontend: always narrow assignment expression used as valuelemon2026-04-111-2/+2
|
* 0.2.5lemon2026-04-111-2/+2
|
* testing: script for csmith fuzz testinglemon2026-04-111-0/+90
|
* irdump: dont print instr numbers by defaultlemon2026-04-111-6/+21
|
* backend: fix memory leak from not calling deluses() after replcuses in some ↵lemon2026-04-114-12/+11
| | | | places
* backend: run mem2reg after inlininglemon2026-04-113-2/+8
|
* x86-64/emit: fix stack arg offset for edgecaseslemon2026-04-111-1/+2
| | | | | It was wrong for functions that didn't use the frame pointer but took arguments in the stack
* c: fix bitfields in unionslemon2026-04-101-4/+6
|
* x86-64/isel: always test for ZF after shiftlemon2026-04-091-3/+3
| | | | | The shift instructions do not update flags if the shift amount was zero, so can't realiably do this micro optimization
* backend: inlining improvementslemon2026-04-093-13/+29
|
* mkintcon: bugfix clamp i32 to i32 rangelemon2026-04-092-3/+5
|
* x86-64/isel: fix stack addr regression from 8b79b61ae7lemon2026-04-091-2/+4
| | | | Checks for RADDR should also look for RSTACK when fusing addresses
* x86-64/isel: use integer stores for storing float constantslemon2026-04-091-2/+16
| | | | | Because the integer mov can have immediate operands, avoids a round trip through an XMM register.
* aarch64 handle more cases of stack relative addressinglemon2026-04-092-3/+21
|
* 0.2.4lemon2026-04-081-2/+2
|
* Implement basic aarch64 struct arg passing ABIlemon2026-04-0810-139/+204
| | | | | | | | | | - Missing: vaargs, >2 member HFAs - Reworked the way stack allocation references are lowered. Now RSTACK persists throughout all passes until emit. This allows deferring stack frame layouting until the end in a less messy way than before, which was emiting frame-pointer relative addresses @ isel time and patching them up later in emit to account for actual stack frame layout.
* x86-64: redzone optimization for leaf functionslemon2026-03-272-9/+12
| | | | Don't use frame pointer or explicitly modify stack pointer for these
* aarch64: GOT relocationslemon2026-03-263-18/+49
|
* driver: try to autodetect crosscc includslemon2026-03-251-0/+21
|
* inliner: fix UB when ninstrtab==0lemon2026-03-251-1/+1
|
* abi: fix use bug preventing mem2reg optimization of struct returnlemon2026-03-252-4/+5
|
* aarch64 struct arg passing ABI wiplemon2026-03-255-11/+127
|
* *skiplemon2026-03-241-1/+1
|
* cpp: support directives within macro argument listlemon2026-03-243-55/+93
| | | | Undefined behavior by the standard but a GNU extension.
* driver: -pthread -> -D_REENTRANT & -lpthreadlemon2026-03-241-1/+4
|
* regalloc: remove dead code for liveness fixuplemon2026-03-241-100/+22
| | | | | | I tested it and it seems this wasn't doing anything. Maybe at some point in the past it was needed to fix up a worse implementation of mem2reg? So turn it into a check. Maybe it's wrong and it can be necessary.
* ir_inliner: redundant checklemon2026-03-241-1/+0
|
* Update todolemon2026-03-241-2/+4
|
* get rid of imap (was only used for mem2reg, no longer)lemon2026-03-242-111/+0
|
* mem2reg rewritelemon2026-03-242-108/+74
| | | | | | | Do it in 2 passes: 1. gather variables, 2. step thru RPO transforming loads/stores to each variable. More elegant solution to f9e3a52eaa. More efficient since all variable usages are visited in CFG order, which matters due to block sealing.
* 0.2.3lemon2026-03-231-2/+2
|
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-01 23:18:44 +0000