- User Since
- Mar 27 2015, 11:23 AM (417 w, 2 d)
Wed, Mar 22
Thu, Mar 16
Looks reasonable to me -- but I'd like to see the LLD change implemented and both pieces tested together end-to-end before this is submitted.
Tue, Mar 7
Mon, Mar 6
+1 Agreed that impl simplicity should be prioritized.
Also, I note the doc says it's useful for for “load address” and “push address” instructions (note, "load address" means e.g. x86 "lea" instruction) -- which should NOT be dependent upon the value stored in the memory. The x86 backend actually uses a "Ts" constraint for *lea<mode> which is defined by define_address_constraint, documented as making a constraint that is basically equivalent to p (just with different limits as to what kinds of addresses are accepted.)
‘p’ in the constraint must be accompanied by address_operand as the predicate in the match_operand. This predicate interprets the mode specified in the match_operand as the mode of the memory reference for which the address would be valid.
It looks to me from GCC that constraint 'p' is intended to be used internally, not for inline-asm. I question whether the kernel should be using it, and whether we should even implement it at all.
Thu, Mar 2
no-compact-unwind is particularly useful for newer x86_64 platforms: we don't want to omit DWARF unwind for x86_64 in general due to possible backwards compat issues, but we should make it possible for people to opt into this behavior if they are only targeting newer platforms.
Tue, Feb 28
So, sigh -- I've just realized this will need a (small) linker change, as well. Currently, we (both LLD and LD64) encode the personality function in the compact-unwind even for unwind infos marked MODE_DWARF.
On the other hand, I think a not-insignificant number of users are interested in freestanding environments for one-off/fun/experimental projects where ease of access is more important than performance characteristics -- think: users who are playing around with an arduino, etc.
Mon, Feb 27
Feb 22 2023
however the fix in most cases should be to use -std=c++2b and the code will work out of the box.
Feb 16 2023
Feb 15 2023
Feb 14 2023
(Firstly, really nobody should be using the __sync_* builtins...)
Given the reassurance regarding optimizations of non-deterministic results, I'm satisfied.
Feb 9 2023
Feb 7 2023
Feb 6 2023
The property of SNaN like SNan + 0.0 -> QNaN is not related to exceptions and must be preserved in default environment also.
Feb 4 2023
As far as I can tell, this conversation has run its course, and I don't think there were any more comments on the actual code, so I'm going to accept this revision.
C standard library's semantics, which state that pow(1.0, NaN) = 1.0, for any NaN
Feb 3 2023
Overall, I think the points we need to convey are here:
- It's assumed that the rounding mode is round-to-nearest, and all floating-point traps are disabled.
- The status flags may be set to arbitrary values.
- Floating-point math operations assume that all NaNs are quiet.
Feb 2 2023
Thanks for the reviews!
Feb 1 2023
For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's
DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame
offset > 2GiB.
Jan 31 2023
I do not believe there's any problem with an isnan to fcmp transform -- as long as we restrict it to non-strictfp functions. And I'm not sure why there's so much debate here. I thought all those sorts of semantic questions were already pretty well settled. Does the documentation about strictfp vs not-strictfp semantics need to be made clearer?
Jan 30 2023
Jan 27 2023
Jan 25 2023
Thanks, looks good now!
Jan 19 2023
Jan 17 2023
This does not matter in practice because these call site tables are all comprehensive
Jan 16 2023
Jan 12 2023
Rename 'cf' field to 'cond' per review request.
Jan 11 2023
Fix transitive_includes test errors.
Add missing auto-generated file, fix review nits.
Jan 10 2023
Now that D136554 has re-landed, it seems that we're now actually good to go here (yay!)
Rebase, rerun ninja libcxx-generate-files, address last review nits.
Jan 9 2023
Hearning no objections, I'll approve this.
Leaving an xref trail here, I filed issues against the two projects I reported above:
Jan 6 2023
Jan 5 2023
I wonder if, at this point, we could just default relax-elf-relocations to true in LLVM -- and potentially even remove the cmake ENABLE_X86_RELAX_RELOCATIONS knob, as well.
AFAIU, the upshot of https://sourceware.org/bugzilla/show_bug.cgi?id=24784 is that -fno-plt is broken after this change, unless -mrelax-relocations is enabled. Clang enables it by default subject to the CMake option ENABLE_X86_RELAX_RELOCATIONS (which defaults to on), but it's disabled by default by LLVM itself.
Jan 4 2023
Now PPC and VE are the last two targets still using useDeprecatedPositionallyEncodedOperands. This change is repetitive and large -- but necessary.
Jan 3 2023
Dec 12 2022
So, I guess these have all been getting actually miscompiled on riscv64 up till now? Whoops!
Dec 10 2022
Dec 8 2022
Thanks for the change.