- User Since
- Jan 4 2017, 12:12 PM (324 w, 6 d)
Fri, Mar 24
The field should just be deleted. D126742 added it without any uses, and I don't know what the original intent was. Maybe it was used before the bitfields were added and it stuck around rather than being GC'ed. I don't know why Coverity would care about this though when it's never read from, there's nothing wrong with that, unless the warning is in fact that the field is entirely unreferenced?
None of the other fields are initialised, so blindly initialising it alone to 0 here seems highly suspect. What's the actual case in which it's used whilst uninitialised?
Wed, Mar 22
Tue, Mar 21
Mon, Mar 20
Sat, Mar 18
Thu, Mar 16
Are there any cases like with all the *W optimisations where it would be better to sign-extend, or is i32 special there due to the *W ops and for i8 the only cases where it's beneficial will already have become sextloads?
Is there a reason we can't instead add the right live-outs?
Mon, Mar 13
Sun, Mar 12
Sat, Mar 11
What happened to your new test?
Wed, Mar 8
Anyway, this definitely still merits a review from @MaskRay given his commit to tackle the problem differently
Anyway this seems to contradict the approach chosen by D127826
Tue, Mar 7
I'm guessing this is so you can llvm-objcopy an ELF into a PE/COFF?.. Because without relocations being defined you can't do much else of use...
Mon, Mar 6
This isn't NFC, the output changes
Fri, Mar 3
A cursory glance reveals numerous cases of ( i1, and cases of undefined variables (e.g. llvm/test/CodeGen/PowerPC/subreg-postra.ll).
Thu, Mar 2
Wed, Mar 1
Feb 24 2023
Feb 22 2023
Normally we use the less cumbersome “MC layer” rather than “assembler and dis-assembler” (which also shouldn’t be hyphenated)
Feb 21 2023
Feb 20 2023
Didn't notice before, but why emutls_generic.ll rather than emutls.ll? The suffix doesn't add any value as far as I can see. It's as generic as any other RISC-V CodeGen test.
Feb 18 2023
Feb 16 2023
Whilst I would encourage wherever this got copied from be cleaned up in a similar manner, I don't think:
- this patch for one backend should be blocked on cleaning up a test in another backend
- a lower-quality test for another backend should be justification for committing a lower-quality test to this backend
https://github.com/riscv/riscv-isa-manual/releases/tag/archive has an assortment of past specs, including the 2.2 you're after
Feb 15 2023
Feb 14 2023
You don’t need to mention FCVTMOD given it does not apply to C/C++.
Feb 13 2023
Personally happy with the concept then, seems consistent and overall helpful, just some nits
I'm fine with this approach but I think they should be filtered out of the ELF attributes, maybe also preprocessor macros? That is, treating them as a redundant no-op in the driver rather than like a true extension.