Mon, Jul 19
Sun, Jul 18
This fixes a problem caused in atomic_load.ll regression test.
Sat, Jul 17
Wed, Jul 14
Thank you for the clarify. As far as I know, our build system for omptarget for VE generates libomptarget.so for VE. Maybe it's the source of problem. I'll discuss with people who implement it for VE about the possibility of separating omptarget itself and runtime. Thanks.
I've noticed this patch breaks libomptarget for VE. The VE is an accelarator, so we create and install clang/llvm for VE as a cross compiler. Then, we build libomptarget for VE using this cross compiler.
Tue, Jun 29
I just commited 913229983633cd4c19b9e5534018f9a42e274b30 which restores VE's previous codegen for i8 and i16 bitreverse. I restored bitreverse.ll to its previous state.
Is it possible to disable this expansion on a architecture which has 64 bit bitreverse and want to promote 32 bit bitreverse to 64 bit?
Feb 1 2021
Jan 29 2021
Jan 24 2021
Jan 19 2021
Hi, I have a question about this patch. I appreciate any answers. Thanks!
Jan 18 2021
Thanks for your contribution. However, it would be useful to have more information before going forward. The goal is to avoid adding random bits of complexity to the library for a system that isn't officially supported and maintained.
- What is VEOS?
- Is this part of an effort to port libc++ to that OS?
- What parts of the library are working on the OS and what parts are not working? Do you plan to subset the library using knobs like LIBCXX_ENABLE_LOCALIZATION=OFF?
- Are you able to provide CI for that OS?
Generally speaking, more information about what prompts this patch is welcome.
Jan 16 2021
Jan 14 2021
Update following suggestions and clang-format.
Jan 13 2021
Jan 12 2021
Jan 11 2021
Jan 8 2021
Jan 7 2021
Not sure what is the problem... Remove profile support to make this patch as simple as possible.
Remove modification on the candidates of profilers.
Leave only modification on the candidates of crt and rebase.
Add explanations too.
Jan 6 2021
Jan 5 2021
A few more modificating candidates to make code better.
Update comments in header file comment which I've forgotten to modify.
Change following suggestions. Also rebase to main.
"Stuff" is unspecific. How about we go by "[VE] SJLJ isel" or something along those lines for the title?
If I understand correctly, this is a chicken-egg problem. You can't upstream the back-end without the RT changes because you have no other RT to rely on (unlike other targets that can use the GCC toolchain). In this case, I think it makes sense that we merge at least some bootstrapping code in RT before the back-end.
Jan 4 2021
Change to use Op.getSimpleValueType() as suggested.
Update following suggestions.
Update following suggestions. Use TLI.getPoitnerTy() this time since
lsda expansion uses machine value type (MVT) instead of value type
structure (EVT) here. Using EVT may require some conversions later.
Dec 27 2020
Dec 26 2020
We are using this patch in llvm/clang for VE and the patch is really helpful to implement intrinsic instructions using vector mask registers. This works fine in backend since backend supports vXi1. I wish people working on clang think this patch is reasonable.
Dec 25 2020
I think we need more reviewer working on not only VVP but also VP to review this patch.
Dec 23 2020
Dec 22 2020
Dec 21 2020
This is what I feel when I see this test. Just a thought. Not a requirement. But, I think it's possible to improve this test in that way.