[SBVec] Refactor BottomUpVec pass for clarity and maintainability
- Corrected comments to clarify the direction of def-use and use-def chains.
- Changed the initialization of the SchedDirection variable to improve clarity.
- Updated documentation in vectorizeRec() to better describe the purpose of UserBndl.
- Removed outdated TODO comment regarding top-down vectorization scheduling.
[SBVec] Add top-down vectorization to the unified Sandbox Vectorizer
Extend the Sandbox Vectorizer's `bottom-up-vec` pass so a single
implementation can vectorize in either direction, and add the top-down
strategy that walks def-use chains forward from a seed.
Direction selection
--------------------
The pass direction is chosen from the Region's auxiliary pass argument:
"bottom-up" (or empty, the default) and "top-down" map onto a
SchedDirection, and any other value is rejected with a fatal usage error.
The vectorizer always runs in the same direction as the scheduler.
Top-down traversal
------------------
Bottom-up starts from a seed slice (e.g. stores to consecutive addresses)
and recurses into operands. Top-down instead starts from a seed of
consecutive loads and recurses into *users*:
[32 lines not shown]
Make result variables obey their dynamic values in subsequent expressions
This is a resubmit of the original patch: 6344e3aa8106dfdfb30cac36c8ca02bc4c52ce24:
Make result variables obey their dynamic values in subsequent
expressions (#168611)
When I originally submitted this, it caused intermittent flakey failures
on systems I didn't have access to, and I didn't have time to sort them
out, so I reverted the patch. I'm resubmitting this so I can run the
bots on it a few rounds to see if I can reproduce and diagnose those
intermittent failures.
Here's the commit log from the original submission describing the
change:
When you run an expression and the result has a dynamic type that is
different from the expression's static result type, we print the result
variable using the dynamic type, but at present when you use the result
[25 lines not shown]
[BranchFolding] Fold away subsequent identical branches
If we have a BB that has a single conditional branch instruction it that
is identical to the previous block's branch instruction, we can delete
the BB as it is redundant.
This doesn't directly impact performance as such instructions are never
executed, but this can help decrease code size which can help with
overall icache pressure (though likely only slightly). The biggest
impact would probably be fitting more instructions into a single cache
line. This is probably almost a no-op with PLO but definitely doesn't
hurt.
Fixes #202763.
Reviewers: RKSimon, arsenm, krzysz00, topperc, lei137
Pull Request: https://github.com/llvm/llvm-project/pull/203110
[SBVec] Refactor BottomUpVec pass for clarity and maintainability
- Corrected comments to clarify the direction of def-use and use-def chains.
- Changed the initialization of the SchedDirection variable to improve clarity.
- Updated documentation in vectorizeRec() to better describe the purpose of UserBndl.
- Removed outdated TODO comment regarding top-down vectorization scheduling.
[SBVec] Add top-down vectorization to the unified Sandbox Vectorizer
Extend the Sandbox Vectorizer's `bottom-up-vec` pass so a single
implementation can vectorize in either direction, and add the top-down
strategy that walks def-use chains forward from a seed.
Direction selection
--------------------
The pass direction is chosen from the Region's auxiliary pass argument:
"bottom-up" (or empty, the default) and "top-down" map onto a
SchedDirection, and any other value is rejected with a fatal usage error.
The vectorizer always runs in the same direction as the scheduler.
Top-down traversal
------------------
Bottom-up starts from a seed slice (e.g. stores to consecutive addresses)
and recurses into operands. Top-down instead starts from a seed of
consecutive loads and recurses into *users*:
[32 lines not shown]
[clang-sycl-linker] Forward all --ocloc-options occurrences to ocloc (#211075)
getLastArgValue() only returned the final --ocloc-options= occurrence,
silently dropping earlier ones when the option is passed multiple
times (one token per occurrence). Use getAllArgValues() so every
occurrence is forwarded to ocloc.
fixup
Have the AST mutation listeners receive any new template specializations,
not just the canonical ones.
This is necessary for modules / the ASTWriter to serialize those.
[clang] fix getTemplateInstantiationArgs
This implements a new strategy for collecting the template arguments, by
relying on the qualifiers and template parameter lists to navigate the template
context of out-of-line definitions.
This greatly simplifies the signature of that function, by removing a bunch
of workarounds, and simpliffying a couple that weren't removed yet.
Since this now relies on qualifiers and template parameter lists,
this patch expends most of its effort making sure these are placed,
transformed and propagated to template instantiations.
Also makes the explicit specialization AST nodes stop abusing the template
parameter lists by storing it's own template parameter list, creating a
dedicated field for them, similar to partial specializations.
[CIR] Classify empty records as Ignore in x86_64 callconv (#211078)
The x86_64 aggregate calling-convention bridge rejects a zero-field
record as NYI, even though the SysV classifier already treats an empty
record as NoClass/NoClass (so it returns Ignore) and the rewriter
already drops arguments and returns classified Ignore.
Dropping the zero-field reject in `isSupportedType` lets a C empty
struct classify as Ignore: the argument slot is removed, the remaining
arguments shift down, and an empty-record return lowers to void.
The C++ empty class stays NYI. CIRGen lays it out as a single padded
byte, which the padded reject still catches. Unions, packed, and
all-float aggregates remain NYI as before.
---------
Co-authored-by: Andy Kaylor <akaylor at nvidia.com>
[Clang] Re-run init-capture initialization when rebuilding default member initializers
When a default member initializer containing a lambda is rebuilt at its
point of use (CWG1815/CWG2631 aggregate initialization),
EnsureImmediateInvocationInDefaultArgs::TransformLambdaExpr transformed
each init-capture initializer with TransformInitializer but never
re-performed the capture's initialization.
TransformInitializer lowers an initializer to its syntactic form -- a
stripped source expression for copy-init, a ParenListExpr for
direct-init, or an InitListExpr for list-init -- and expects the
enclosing context to rebuild the initialization against the target
entity. Without that second step the rebuilt closure was left with a
bare capture initializer: CodeGen crashed for a trivially destructible
closure (aggregate-copy of a non-trivially copyable type) and silently
left the capture uninitialized otherwise.
Re-run buildLambdaInitCaptureInitialization on the transformed
initializer, as the canonical TreeTransform::TransformLambdaExpr does, so
[7 lines not shown]
[CIR] Report NYI for defaulted union copy/move assignment
A defaulted union copy or move assignment operator has an empty synthesized
body because Sema skips union fields, leaving no AST expression for the
implied whole-object copy. CIRGen emitted that empty body and silently
dropped the assignment.
Report NYI for defaulted union assignment instead. Struct and array
assignments are unaffected because their synthesized bodies contain the
memberwise copies needed by the existing body-emission path.
[llvm-reduce] Unconditionally initialize targets
It is not expensive to do, and doing it unconditionally avoids edge
cases like the one in the added test case.
Reviewers: arsenm, mtrofin
Pull Request: https://github.com/llvm/llvm-project/pull/208966
[llvm-reduce] Run AssignGUIDPass when loading BC
Otherwise we run into crashes when loading BC that has a module summary. This is a no-op if we load existing GUIDs, so probably makes sense to run regardless.
Reviewers: mtrofin
Pull Request: https://github.com/llvm/llvm-project/pull/208965
