-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CIR] Extend support for floating point attributes #572
base: main
Are you sure you want to change the base?
Conversation
This reverts commit 55c03f8
This is going to be used to raise `cir.call`s to `std::find(...)` into `cir.std.find`.
Also implement lowering back to `std::call` before lowering to LLVM.
…lvm#353) This PR fixes a global vars lowering with a funciton ptr field. Previously, the next code caused fail in the `foo` lowering: ``` static void myfun(int a) {} static struct { void (*func)(int flag); } const Handlers[] = { {myfun}, {myfun}, {myfun} }; void foo(int i, int flag) { Handlers[i].func(flag); } ```
This is the first part of implementing vector types and vector operations in ClangIR, issue llvm#284. This is enough to compile this test program. I haven't tried to do anything beyond that yet. ``` typedef int int4 __attribute__((vector_size(16))); int main(int argc, char** argv) { int4 a = { 1, argc, argc + 1, 4 }; int4 b = { 5, argc + 2, argc + 3, 8 }; int4 c = a + b; return c[1]; } ``` This change includes: * Fixed-sized vector types which are parameterized on the element type and the number of elements. For example, `!cir.vector<s32i x 4>`. (No scalable vector types yet; those will come later.) * New operation `cir.vec` which creates an object of a vector type with the given operands. * New operation `cir.vec_elem` which extracts an element from a vector. (The array subscript operation doesn't work here because the result is an rvalue, not an lvalue.) * Basic binary arithmetic operations on vector types, though only addition has been tested. There are no unary operators, comparison operators, casts, or shuffle operations yet. Those will all come later.
…vm#356) This PR adds a support for the multi-block case statements. Previously, the code example below caused crash in cir verification Lowering to the `llvm` dialect is pretty straightforward: the same logic as before is applied to all the region's blocks with no successors, i.e. we no longer think a case/default region contains only one block. The `CodeGen` part is a little bit tricky. Previously, any sub-statement of `case` or`default`, that was not any of them (i.e. neither `case` nor `default`) was processed with an insertion guard, meaning that the next sub-statement in the same clause was inserted again in the same block as the first one. It would be fine, once sub-statement didn't generate any blocks as well. For instance, ``` void foo(int a) { switch (a) { case 3: return; break; } } ``` The `return` statement actually emit a new block after, where the unreachable code with `break` should be inserted in. That's why we also need to update `lastCaseBlock` while generating `cir.switch` This is quite frequent bug in `llvm-test-suite`
This contains just the skeleton, but the idea is that this pass is going to contain transformations done on top CIR generated by the C/C++ idiom recognizer.
Specify proper target triples to prevent issues on both Windows and MacOS regarding non-implemented ABI bits.
Only a skeleton for incremental work.
Initial step into modeling iterators in CIR. Right now it only looks at the member functions with .begin/.end function calls, it does not look at the iterator type, has no notion of forward/reverse iterators, nor filters based on the container types - those improvements will come next.
…#355) Before this fix attached test case has been failing due to type mismatch (signed vs unsigned).
Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`
This PR "adds" the support of extern vars in function body. Actually, I just erased an assert. Any reason it was there? ``` int foo() { extern int optind; return optind; } ``` This is quite frequent bug in `llvm-test-suite`
This PR adds `cir.stack_save` and `cir.stack_restore` operations.
…m#357) This PR fixes lowering of the next code: ``` void foo(int x, int y) { switch (x) { case 0: if (y) break; break; } } ``` i.e. when some sub statement contains `break` as well. Previously, we did this trick for `loop`: process nested `break`/`continue` statements while `LoopOp` lowering if they don't belong to another `LoopOp` or `SwitchOp`. This is why there is some refactoring here as well, but the idea is stiil the same: we need to process nested operations and emit branches to the proper blocks. This is quite frequent bug in `llvm-test-suite`
This is how both libc++ and libstdc++ implement iterator in std::array, stick to those use cases for now. We could add other variations in the future if there are others around.
- Check whether container is part of std, add a fixed list of available containers (for now only std::array) - Add a getRawDecl method to ASTRecordDeclInterface - Testcases
This was a bit half backed, give it some love.
Inspired by similar work in libc++, pointed to me by Louis Dionne and Nikolas Klauser. This is initial, very conservative and not generalized yet: works for `char`s within a specific version of `std::find`.
…ents. Before this fix conversion of flat offset to GlobalView indices could crash or compute invalid result.
This reverts commit bbaa147.
`ScopeOp` may end with `ReturnOp` instead of `YieldOp`, that is not expected now. This PR fix this. The reduced example is: ``` int foo() { { return 0; } } ``` This is quite frequent bug in `llvm-test-suite`
One more step towards variable length array support. This PR adds one more helper for the `alloca` instruction and re-use the existing ones. The reason is the following: right now there are two possible ways to insert alloca: either to a function entry block or to the given block after all the existing alloca instructions. But for VLA support we need to insert alloca anywhere, right after an array's size becomes known. Thus, we add one more parameter with the default value - insertion point. Also, we don't want copy-paste the code, and reuse the existing helpers, but it may be a little bit confusing to read.
This PR adds `cir.ternary` lowering. There are two approaches to lower `cir.ternary` imo: 1. Use `scf.if` op. 2. Use `cf.cond_br` op. I choose `scf.if` because `scf.if` + canonicalization produces `arith.select` whereas `cf.cond_br` requires scf lifting. In many ways `scf.if` is more high-level and closer to `cir.ternary`. A separate `cir.yield` lowering is required since we cannot directly replace `cir.yield` in the ternary op lowering -- the yield operands may still be illegal and doing so produces `builtin.unrealized_cast` ops. I couldn't figured out a way to solve this issue without adding a separate lowering pattern. Please let me know if you know a way to solve this issue.
This PR fixes the next case ``` typedef struct { } A; A create() { A a; return a; } void foo() { A a; a = create(); } ``` i.e. when a struct is assigned to a function call result
ASMParser::parseAttribute is responsible for emitting its own errors or forwarding errors of the parsers below it. There is no reason to emit a subsequent error as it doesn't add extra information to the user. As a driveby, beutify a bit the tests that "relied" on this error and make the expected error easier to read by moving it to the line before.
…m#568) Add left long double types lowering for cos operation llvm#565 --------- Signed-off-by: zhoujing <[email protected]>
Upstream patch: llvm/llvm-project#90442 |
c4db6d0
to
e197d4e
Compare
Nathan just did a rebase, can you please update? Sorry for the churn |
This commit introduce CIRGlobalOpLowering and CIRGetGlobalOpLowering for lowering to memref.
Parsing support for floating point types was missing a few features: 1. Parsing floating point attributes from integer literals was supported only for types with bitwidth smaller or equal to 64. 2. Downstream users could not use `AsmParser::parseFloat` to parse float types which are printed as integer literals. This commit addresses both these points. It extends `Parser::parseFloatFromIntegerLiteral` to support arbitrary bitwidth, and exposes a new API to parse arbitrary floating point given an fltSemantics as input. The usage of this new API is introduced in the Test Dialect.
This commit extends the support for floating point attributes parsing by using the new `AsmParser::parseFloat(fltSemnatics, APFloat&)` interface. As a drive-by, this commit also harmonizes the cir.fp print/parse namespace usage, and adds the constraint of supporting only "CIRFPType"s for cir.fp in tablegen instead of verifying it manually in the parsing logic.
Rebased 🙏 |
Thanks for going the extra length to make sure this works! |
Merged upstream 🎉 |
@bcardosolopes - is there any planned rebase anytime soon? This PR is blocked by getting the upstream patch. Alternatively, I assume we can cherry-pick it here and there's a 95% chance that it will dissolve on the next rebase. Let me know what you prefer 🙏🏼 |
@lanza wdyt? |
I pushed a rebase just now. Should be good to go :p |
This commit extends the support for floating point attributes parsing by using
the new
AsmParser::parseFloat(fltSemnatics, APFloat&)
interface.As a drive-by, this commit also harmonizes the cir.fp print/parse namespace
usage, and adds the constraint of supporting only "CIRFPType"s for cir.fp in
tablegen instead of verifying it manually in the parsing logic.
This commit is based on top of a to-be-upstreamed commit which extends the upstream MLIR float type parsing. Upstream parsing of float type has full capability only through parsing the Builtin Dialect's
FloatAttr
. Thos commit exposes the same capabilities to downstream users.This PR should resolve (at least)
GCC-C-execute-ieee-fp-cmp-2
andGCC-C-execute-ieee-fp-cmp-4
, paving the way to otherGCC-C-execute-ieee-*
tests passing from the SingleSource suite. It resolves #559 .