[libc++] Don't require complete types in vector<T>::empty() (#210754)
This was previously not required, but the patch to introduce a new
size-based vector layout unintentionally added this new requirement. We
almost certainly not want to promise this guarantee going forward, but
we should actually land this change explicitly and consider the
transition story, not do it as a fallout of another refactoring.
Fixes #210732
[GlobalISel] Use correct fp semantics when building constants. (#210190)
This bug can materialize as a `bfloat 1.0` becoming `0x3C00` which is
the bit pattern for `half 1.0`. After this change, `0x3F80` is correctly
returned.
The fix is to use the destination type to convert the provided
constant's semantics in `buildFConstant`. Added a unit test.
Removed `getAPFloatFromSize`, no more users.
[DirectX] Add slim debug support (#204459)
When DXC is called with `/Zs` flag, it emits "slim" debug info. It means
that ILDB section is omitted from the main DXContainer output and from
the output PDB file.
This patch reimplements similar behavior in llc, introducing
`--dx-slim-debug` flag.
[flang][OpenMP] Add semantic checks for two DECLARE VARIANT restrictions (#209528)
Diagnose two DECLARE VARIANT restrictions from the OpenMP specification
(5.2 [7.5], 6.0 [9.6]) that were previously accepted without error:
- If a procedure is determined to be a function variant through more
than one DECLARE VARIANT directive, the construct selector set of their
context selectors must be the same.
- A procedure determined to be a function variant may not be specified
as a base function in another DECLARE VARIANT directive.
Assisted-by: Cursor
[Flang] [OpenMP] Run `MarkDeclareTarget` pass again before `HostOpFiltering` (#210049)
Fixes #209123.
The power operation `math.ipowi` is converted to a function by
`ConvertMathToFuncs`. When used in a target region, this pass runs well
after `MarkDeclareTarget` which causes the newly created power function
to not have the `omp.declare_target` attribute, which in turn trips up
the `HostOpLowering` pass. Detailed investigation
[here](https://github.com/llvm/llvm-project/issues/209123#issuecomment-4991765854).
Right now, I've just added a couple of lines to run `MarkDeclareTarget`
again, before `HostOpFiltering`. Since I'm quite new to this, I'd like
some help on whether this is acceptable, or should the
`MarkDeclareTarget` pass be moved to after `ConvertMathToFuncs` and
before `HostOpFiltering`.
[PowerPC] Add _Complex _Float16 and homogeneous-aggregate ABI tests
Pin down two calling-convention decisions requested in review:
- _Complex _Float16 is passed and returned as two scalar half components
(real, imaginary), each in an FPR, consistent with the scalar rule and
the psABI treatment of complex types.
- A struct of _Float16 members is not a homogeneous floating-point
aggregate: it is passed as an integer aggregate (GPRs on ELFv2, byval
on AIX), contrasted with a float aggregate that does use FPRs. The HFA
question for _Float16 is deliberately left to the psABI.
[PowerPC] Fix f16 int conversions, varargs and calling convention
Fix a set of defects in the f16 support found by runtime testing on
Power10 hardware (Linux ELFv2 and AIX) and by review:
- FP_TO_SINT/FP_TO_UINT with an f16 operand are keyed by the legalizer on
their (legal) integer result type, so the operand was never promoted and
mis-selected as a double-precision convert, producing silently wrong
results. Add a DAG combine that extends the operand to f32 first.
- SINT_TO_FP/UINT_TO_FP with an f16 result fell back to a nonexistent
__floatdihf/__floatundihf libcall for i64 sources. Round through f64
(fcfid/xscvsxddp then xscvdphp) with a matching combine.
- A variadic f16 argument on ELFv2 hit a BITCAST width assertion in
LowerCall_64SVR4 when producing the GPR copy of an unnamed FP argument.
Handle f16 with BITCAST to i16 then ANY_EXTEND, mirroring the f32 path.
- The CC_PPC64_ELF shadow-GPR helper did not count f16, so a scalar f16
argument failed to reserve its GPR doubleword in the CCState analysis
used for tail-call and stack-size decisions.
- Map VHFRC to the 8-byte VSX spill slot: the 16-bit value lives in the
[7 lines not shown]
[PowerPC] Add f16 strict-FP support
Registering f16 as a legal type left every STRICT_* opcode at its Legal
default with no selection pattern, so any strict-FP operation on
_Float16 failed to select. Fix the strict path end to end:
- Promote the strict arithmetic, rounding, transcendental and compare
opcodes (STRICT_FSETCC/STRICT_FSETCCS) to f32 via F16StrictPromoteOps.
- Switch the P9 conversion patterns to any_fpround/any_fpextend so the
strict nodes select XSCVDPHP/XSCVHPDP directly.
- Make LowerFP_EXTEND strict-aware (thread the chain) and route P9
f16 -> f128 through xscvhpdp + xscvdpqp instead of regressing to an
__extendhfsf2 libcall; register STRICT_FP_EXTEND Custom for the f16
source cases, re-applied after the generic f32/f64 Legal setting that
would otherwise clobber it.
- Build STRICT_FP_ROUND in the int-to-fp combine with a target rounding
mode constant, fixing an "Invalid STRICT_FP_ROUND!" assertion on
strict sitofp/uitofp to f16.
- Suppress register pressure set generation for VHFRC, which shares the
[4 lines not shown]
[PowerPC] Remove the float16 target feature; make -mfloat16 front-end-only
Delete FeatureFloat16 and the HasFloat16 predicate from PPC.td and stop
emitting +float16 from the driver. -mfloat16 is now marshalled to
LangOpts.PPCFloat16 and forwarded to cc1 directly; its validation (Power8+
requirement, -msoft-float conflict) moves from the driver feature handling
into PPCTargetInfo::adjust().
The flag is purely a source-level admission gate for the _Float16 type.
It produces no LLVM target feature and has no effect on the
target-features attribute, so ABI and code generation depend only on
hardware capability (hasP8Vector() && hasHardFloat()): two translation
units compiled with and without -mfloat16 have identical calling
conventions.
[PowerPC] Fix f16 BR_CC promotion and update stale AIX TOC test checks.
- Add ISD::BR_CC to F16PromoteOps so half-precision branch conditions
are promoted to f32 before reaching SelectCC in PPCISelDAGToDAG.
Without this, fcmp+br on f16 operands crashed with an assertion in
SelectCC which only handles f32/f64/f128 comparisons.
- Regenerate half-float16-ppc.ll: AIX TOC addressing for constant pool
entries changed upstream from a single GP-relative ld (ld 3,L..C0(2))
to an explicit hi/lo addis+ld pair; update the P8-AIX-64 CHECK lines.
- Regenerate soft-promote-half-br-cc.ll: with f16 arguments now arriving
in FPRs (f1,f2) rather than GPRs (r3,r4) post ABI fix, update all
CHECK patterns to reflect the FPR-based calling convention.
[SDAG] Use DAG.getTokenFactor in more places (#210949)
This will cause the TokenFactor to be split into nodes of at most
SDNode::getMaxNumOperands() size.
This fixes #189161 but I have not added a test case as the output is
in excess of 160000 lines long.
[FileCheck][NFC] Encapsulate more into InputAnnotationLabeler (#207484)
This patch migrates more label-making concerns from
buildInputAnnotations into the InputAnnotationLabeler. It also
eliminates the brittle approach of creating a new InputAnnotationLabeler
object with a separate label prefix upon each MatchResultDiag while
persisting an object to close the previous search range. Instead, this
patch creates just one InputAnnotationLabeler object to handle all
diags, and it maintains a table of label prefixes for check patterns.
That approach seems easier to understand and more amenable to code
evolution.
[VPlan] Remove additional stray whitespace when printing calls. (#210979)
VPWidenCallRecipe::print had a stray whitespace between call and
fucntion name. Strip stray whitespace and add strict whitespace test to
guard against regressions.
AMDGPU/GlobalISel: Clean up fp LLT usage in AMDGPULegalizerInfo
Remove local variables in favor of global F16/BF16/F32/F64/V2F16/V2BF16.
These are now proper floating point LLTs instead of LLT::scalar.
A couple of legalizer actions now use fp extended LLT for type checks.
This is intended and is planned for all floating point opcodes.
In most cases the current S16/S32/S64 action on floating point opcodes was
intended for F16/F32/F64, and we will need to define an action for BF16.
[CostModel][X86] getArithmeticReductionCost - convert to CostKindTblEntry entries. NFC. (#210969)
No actual cost changes yet, but makes it much easier to adjust costs as
we progress.
[GVN] Remove unused debug helper (NFC) (#210333)
The `GVNPass::dump` method is not used anywhere. Moreover, there's no
`GVNPass` state that corresponds to its parameter type. Even if a
`GVNPass::dump` method could be useful, this one wasn't it.
[DAGCombiner] Teach MatchLoadCombine to look through AND masks (#200247)
Fixes #191193
`MatchLoadCombine` can combine OR trees built from shifted/zexted
consecutive byte loads into a wider load, but it currently bails out
when one of the loaded bytes is masked before being shifted into place.
This will miss patterns such as the following
```
zext(load i8 p) | (zext(and(load i8 p+1, 3)) << 8)
```
which can be implemented as a 16-bit load followed by a mask.
This PR teaches `calculateByteProvider()` to look through constant AND
masks by tracking the mask applied to each byte. When the byte providers
cover a consecutive load range, we form the wider load and apply a final
mask to preserve the original value.
Added X86 and AArch64 tests covering the masked-byte combine, plus
[3 lines not shown]
[Darwin][TSan] Fix race in mach_vm_deallocate interceptor (#210716)
I have seen an issue whereby the meta store in MetaMap::AllocBlock lands
in the unmapped gap left during the tsan::MetaMap::ResetRange call;
where the range is first unmapped, and then remapped with MAP_FIXED.
This occurred under the mach_vm_deallocate interceptor, because it first
does the deallocate call, and only then does it call UnmapShadow -
leaving a gap where a fresh slab for malloc can land, only to have the
meta region for that range mapped out from under it, resulting in a bad
access fault.
It is worth noting that there is a comment above the IsValidMmapRange
function (which gets called during UnmapShadow), that describes this
exact issue in the context of munmap.
rdar://179172055
Assisted by: Claude
