- User Since
- May 10 2016, 6:42 AM (161 w, 6 d)
Thu, May 23
Wed, May 22
Tue, May 21
Thanks @lewis-revill this LGTM.
May 15 2019
I have a question about the meaning of the vlen operand so I want to double-check here.
May 2 2019
May 1 2019
I've been looking into this and I have some observations, but not a satisfactory solution so far.
Apr 17 2019
James, Alex: Thanks a lot for the comments. I'll look into what I can do here.
I don't like resurrecting old reviews. This is just a warning in advance of a future issue we will have with the RISC-V backend when exception handling is enabled (it is not yet upstream).
Apr 15 2019
Apr 13 2019
Apr 11 2019
Thanks a lot for the review Alex!
- Improve comment with wording kindly suggested by Alex Bradbury
Apr 10 2019
Apr 5 2019
Lewis, Alex: thanks for the review.
Apr 3 2019
- Remove dead phi in the test
Apr 2 2019
Mar 30 2019
Thanks for the update Alex, certainly vararg.ll is a better test to update than my earlier suggestions.
Mar 26 2019
Mar 25 2019
Thanks Alex. I will commit it shortly.
Mar 18 2019
Thanks a lot for this Alex.
Mar 14 2019
Looks good to me, just a minor suggestion above.
Mar 13 2019
Feb 19 2019
Looks sensible to me.
Feb 1 2019
Jan 28 2019
@jmorse pr40427.ll uses x86-specific bits in the CHECK lines and is causing failures in builds that do not target by default x86 (e.g. http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/16847 )
Jan 25 2019
Hi @lewis-revill, thanks for the patch.
Jan 23 2019
Jan 16 2019
Jan 14 2019
Ah, I think what happens is that we should not emit such patterns without the presence of the F extension: these patterns are ultimately selected as instructions in F. Does this make sense?
Jan 8 2019
Dec 21 2018
Dec 14 2018
Minor comment above but other than that this looks good to me too.
Dec 10 2018
The build issue was fixed in rL348783
Dec 7 2018
Upstream recently amended the ABI spec so it looks to me this is not going to be needed.
Dec 6 2018
My only problem with that approach is that it seems wrong to expand PseudoLLA the same way I am expanding PseudoAddrPCRel, IE allowing the AUIPC operand to be decided by codegen.
Dec 5 2018
Ah of course. I hadn't thought of that case. I guess we don't expect symbols to end in @plt as part of their name, do we?
Would it make sense to add an operand that allows a bare symbol or bare symbol + @plt and use it only in CALL and TAIL instead of allowing identifier@plt everywhere?
Dec 4 2018
Yeah, upstream suggested axing the list of assembly operators from the psABI doc as it's unnecessary duplication that gets out of date. Volunteers?...
Ah, thanks @asb definitely I was looking at the wrong place!
This patch is a very reasonable one: it is a bit weird we can't expand la (under -fPIC) because R_RISCV_GOT_HI20 relocation does not have any associated syntax.
Hi, thanks for the patch. I don't think this usage is wrong so we don't have to change it.
Dec 3 2018
Thanks both for the prompt answer!
the test MC/Disassembler/RISCV/invalid-instruction.txt contains this case
Nov 21 2018
In my downstream I have a single RISCVISD::WRAPPER_PIC and then I use a target flag to remember whether later we want just PCREL (lla) or GOT based on what shouldAssumeDSOLocal returns.
Nov 13 2018
Nov 7 2018
On hold for now.
Thanks Luis. I merged your earlier change D54034 into my downstream compiler just to find that frem was missing (triggered by a downstream test).
Nov 6 2018
Oct 31 2018
Here is an example of two dvl invocations, which compute the same result:
a) llvm_dvl_fadd.v256f64(%x, %y, <full mask>, 13)
Since 13 < 32, the hardware will only issue 1 operation to its SIMD execution units. The occupation is thus something like 13/32 ~ 40%.
b`) llvm_dvl_fadd.v256f64(%x, %y, <mask with first 13 bits set>, 256)
Since the DVL is 256, the hardware will issue 8 operations to its SIMD units. However, only the first 13 elements are relevant leading to an occupation of 13/256 ~ 5%.
I agree with @fpetrogalli here that there is some overlap between a "dynamic vector length" i32 %dvl and a mask of the form %m = <i1 0, ..., i1 0, i1 1, ..., i1 1> (or the reverse, if the lanes are to be interpreted in the other direction) where %dvl = llvm.ctpop(%m). As Francesco, puts it, we can always construct %m from %dvl. Perhaps I'm wrong, but I think in the context of strip-mined loops or whole function vectorisation, more elaborated masks that might arise due to control flow would always be subsumed by %m (i.e. will have a strict subset of the lanes enabled by %dvl).
Oct 30 2018
Hi @efriedma thanks a lot for this improvement.
Oct 25 2018
Oct 24 2018
Yes, the changes in this RFC are compatible with a physical simdlen that is unknown at compile time.
Oct 23 2018
Oct 22 2018
Oct 15 2018
Oct 4 2018
Sorry I missed the RFC. After having read it I agree with you. Sorry for the noise.
Oct 3 2018
rv64i has a few specific *w instructions that we probably want to test them too. For instance,
Sep 12 2018
The updated testcase does not fail locally anymore.
Thanks I will do it shortly.
I can commit it.
Thanks for the review!
on a second thought, "InstalledDir" only appears with -v, and is still too fragile (e.g if installed dir name also contains checked strings)
Sep 10 2018
Sure, I didn't mean to do that broader change here. Apologies if it read that way.
Thanks for reopening this @kristina.