https://github.com/fhahn reopened
https://github.com/llvm/llvm-project/pull/93499
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/93499
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/93499
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/93499
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/93499
>From 1ce660b45d3706912705bc9e7a8c19e86f05d0c0 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Wed, 8 May 2024 20:47:29 +0100
Subject: [PATCH] [LAA] Use getBackedgeTakenCountForCountableExits.
Update LAA to use
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/93499
Update LAA to use getBackedgeTakenCountForCountableExits which returns
the minimum of the countable exits
When analyzing dependences and computing runtime checks, we need the
smallest upper bound on the number of
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/91962
>From ab0311667695fb255625cc846e02373800fad8b1 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Wed, 1 May 2024 11:03:42 +0100
Subject: [PATCH 1/3] [SCEV,LAA] Add tests to make sure scoped SCEVs don't
impact
fhahn wrote:
SGTM
https://github.com/llvm/llvm-project/pull/91092
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/91964
Use SCEVUse from https://github.com/llvm/llvm-project/pull/91961 to return a
SCEVUse with use-specific no-wrap flags for GEP expr, when demanded.
Clients need to opt-in, as the use-specific flags may not be valid
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/91962
Use SCEVUse to add a NUW flag to the upper bound of an accessed pointer.
We must already have proved that the pointers do not wrap, as otherwise
we could not use them for runtime check computations.
By adding the
https://github.com/fhahn approved this pull request.
LG to be back-ported if desired. It fixes an mis-compile but I am not aware of
any end-to-end reports. I am not sure what the criteria for cherry-picks on the
release branch are at this point in the release
https://github.com/fhahn approved this pull request.
Should be safe to back port, LGTM, thanks!
https://github.com/llvm/llvm-project/pull/91286
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn approved this pull request.
LGTM, thanks!
For the title, it might be clearer to explicitly mention the variable this is
documenting, commit title size permitting
https://github.com/llvm/llvm-project/pull/90670
___
fhahn wrote:
Added compiler-rt tests for various strict-aliasing violations from the bug
tracker I found.
https://github.com/llvm/llvm-project/pull/76261
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn reopened
https://github.com/llvm/llvm-project/pull/88039
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/88039
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
fhahn wrote:
> > > I would enjoy more textual description of what every condition is meant
> > > to check.
> >
> >
> > There are multiple places that hand off reasoning to called functions,
> > would you like to have a summary of what the function checks there? Could
> > do as separate
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/88039
>From 110e5ea24d4b23a153b5f602460b81e5228c700f Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Thu, 4 Apr 2024 12:36:27 +0100
Subject: [PATCH 1/5] [LAA] Support different strides & non constant dep
distances
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/88039
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -720,7 +726,7 @@ if(COMPILER_RT_SUPPORTED_ARCH)
endif()
message(STATUS "Compiler-RT supported architectures:
${COMPILER_RT_SUPPORTED_ARCH}")
-set(ALL_SANITIZERS
asan;dfsan;msan;hwasan;tsan;safestack;cfi;scudo_standalone;ubsan_minimal;gwp_asan;asan_abi)
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/76261
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/76260
>From 96912aec51f6752d211d8bd091eaad6426037050 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Thu, 18 Apr 2024 23:01:03 +0100
Subject: [PATCH 1/2] [TySan] A Type Sanitizer (Clang)
---
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/76260
>From 96912aec51f6752d211d8bd091eaad6426037050 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Thu, 18 Apr 2024 23:01:03 +0100
Subject: [PATCH 1/2] [TySan] A Type Sanitizer (Clang)
---
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/76260
error: too big or took too long to generate
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/76260
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
fhahn wrote:
Could you remove the commit-id line from the commit message, as it doesn’t seem
relevant?
https://github.com/llvm/llvm-project/pull/86072
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn approved this pull request.
LGTM, would be good to back-port.
https://github.com/llvm/llvm-project/pull/83129
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/84227
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn reopened
https://github.com/llvm/llvm-project/pull/77790
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/77790
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/82793
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
fhahn wrote:
@ayalz unfortunately I don't know how to update the target branch to
`llvm:main`, so I went ahead and opened a new PR that's update on top of
current `main`: https://github.com/llvm/llvm-project/pull/83068
Comments should be addressed, sorry for the inconvenience.
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/80273
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/77790
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn commented:
@dobbelaj-snps Added a substantial number of tests that should cover all cases
now in 2a9b86cc10c3883cca51a5166aad6e2b755fa958
https://github.com/llvm/llvm-project/pull/81289
___
llvm-branch-commits mailing list
@@ -4561,6 +4577,10 @@ bool SROA::presplitLoadsAndStores(AllocaInst ,
AllocaSlices ) {
PStore->copyMetadata(*SI, {LLVMContext::MD_mem_parallel_loop_access,
LLVMContext::MD_access_group,
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/81289
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/81289
>From 90639e9131670863ebb4c199a9861b2b0094d601 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Fri, 9 Feb 2024 15:17:09 +
Subject: [PATCH 1/2] [SROA] Use !tbaa instead of !tbaa.struct if op matches
field.
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/81289
>From 90639e9131670863ebb4c199a9861b2b0094d601 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Fri, 9 Feb 2024 15:17:09 +
Subject: [PATCH] [SROA] Use !tbaa instead of !tbaa.struct if op matches field.
If a
fhahn wrote:
> lgtm
>
> Maybe rephrase the commit message to something like:
>
> ```
> [tbaa] Use !tbaa for first accessed field if it is an exact match in offset
> and size.
> ```
Updated, thanks! It would be great if you could take another look at
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/81313
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
fhahn wrote:
> Hmm. 10 changes + 1 new usage of setAAMetaData, But only 4 relevant changes
> in tests.. That part of SROA seems to lack some testing ?
Yes, will add the missing coverage, just wanted to make sure this makes sense
in general beforehand
@@ -7,9 +7,9 @@ define void @load_store_transfer_split_struct_tbaa_2_float(ptr
dereferenceable(2
; CHECK-NEXT: entry:
; CHECK-NEXT:[[TMP0:%.*]] = bitcast float [[A]] to i32
; CHECK-NEXT:[[TMP1:%.*]] = bitcast float [[B]] to i32
-; CHECK-NEXT:store i32 [[TMP0]],
@@ -821,13 +821,15 @@ MDNode *AAMDNodes::extendToTBAA(MDNode *MD, ssize_t Len) {
AAMDNodes AAMDNodes::adjustForAccess(unsigned AccessSize) {
AAMDNodes New = *this;
MDNode *M = New.TBAAStruct;
- New.TBAAStruct = nullptr;
if (M && M->getNumOperands() == 3 &&
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/81313
Motivation for this and follow-on patches is to improve codegen for libc++,
where using memcpy limits optimizations, like vectorization for code iteration
over std::vector>: https://godbolt.org/z/f3vqYos3c
@@ -821,13 +821,15 @@ MDNode *AAMDNodes::extendToTBAA(MDNode *MD, ssize_t Len) {
AAMDNodes AAMDNodes::adjustForAccess(unsigned AccessSize) {
AAMDNodes New = *this;
MDNode *M = New.TBAAStruct;
- New.TBAAStruct = nullptr;
if (M && M->getNumOperands() == 3 &&
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/81289
If a split memory access introduced by SROA accesses precisely a single field
of the original operation's !tbaa.struct, use the !tbaa tag for the accessed
field directly instead of the full !tbaa.struct.
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/81285
Retain TBAAStruct if we fail to match the access to a single field. All users
at the moment use this when using the full size of the original access. SROA
also retains the original TBAAStruct when accessing parts
@@ -537,6 +542,30 @@ void VPlanTransforms::optimizeInductions(VPlan ,
ScalarEvolution ) {
bool HasOnlyVectorVFs = !Plan.hasVF(ElementCount::getFixed(1));
VPBasicBlock::iterator InsertPt = HeaderVPBB->getFirstNonPhi();
for (VPRecipeBase : HeaderVPBB->phis()) {
+if
@@ -489,15 +489,18 @@ void VPlanTransforms::removeDeadRecipes(VPlan ) {
}
}
-static VPValue *createScalarIVSteps(VPlan , const InductionDescriptor ,
+static VPValue *createScalarIVSteps(VPlan ,
+InductionDescriptor::InductionKind Kind,
@@ -489,6 +490,23 @@ Value *VPInstruction::generateInstruction(VPTransformState
,
return ReducedPartRdx;
}
+ case VPInstruction::PtrAdd: {
+if (vputils::onlyFirstLaneUsed(this)) {
+ auto *P = Builder.CreatePtrAdd(
+ State.get(getOperand(0),
@@ -546,9 +575,10 @@ void VPlanTransforms::optimizeInductions(VPlan ,
ScalarEvolution ) {
continue;
const InductionDescriptor = WideIV->getInductionDescriptor();
-VPValue *Steps = createScalarIVSteps(Plan, ID, SE, WideIV->getTruncInst(),
-
@@ -2503,6 +2504,12 @@ class VPDerivedIVRecipe : public VPSingleDefRecipe {
dyn_cast_or_null(IndDesc.getInductionBinOp()),
Start, CanonicalIV, Step) {}
+ VPDerivedIVRecipe(InductionDescriptor::InductionKind Kind, VPValue *Start,
+
@@ -515,6 +533,8 @@ void VPInstruction::execute(VPTransformState ) {
State.Builder.setFastMathFlags(getFastMathFlags());
for (unsigned Part = 0; Part < State.UF; ++Part) {
Value *GeneratedValue = generateInstruction(State, Part);
+if (!GeneratedValue)
+
@@ -537,6 +542,30 @@ void VPlanTransforms::optimizeInductions(VPlan ,
ScalarEvolution ) {
bool HasOnlyVectorVFs = !Plan.hasVF(ElementCount::getFixed(1));
VPBasicBlock::iterator InsertPt = HeaderVPBB->getFirstNonPhi();
for (VPRecipeBase : HeaderVPBB->phis()) {
+if
@@ -515,6 +533,8 @@ void VPInstruction::execute(VPTransformState ) {
State.Builder.setFastMathFlags(getFastMathFlags());
for (unsigned Part = 0; Part < State.UF; ++Part) {
Value *GeneratedValue = generateInstruction(State, Part);
+if (!GeneratedValue)
+
@@ -857,11 +857,7 @@ void VPlan::execute(VPTransformState *State) {
Phi = cast(State->get(R.getVPSingleValue(), 0));
} else {
auto *WidenPhi = cast();
-// TODO: Split off the case that all users of a pointer phi are scalar
-// from the
@@ -537,6 +542,30 @@ void VPlanTransforms::optimizeInductions(VPlan ,
ScalarEvolution ) {
bool HasOnlyVectorVFs = !Plan.hasVF(ElementCount::getFixed(1));
VPBasicBlock::iterator InsertPt = HeaderVPBB->getFirstNonPhi();
for (VPRecipeBase : HeaderVPBB->phis()) {
https://github.com/fhahn approved this pull request.
LGTM as this fixes a miscompile
https://github.com/llvm/llvm-project/pull/80274
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn approved this pull request.
LGTM, thanks!
Should be low risk and good to have this fixed in the release
https://github.com/llvm/llvm-project/pull/79561
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/80271
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/80273
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/80271
At the moment, some VPInstructions create only a single scalar value, but use
VPTransformatState's 'vector' storage for this value. Those values are
effectively uniform-per-VF (or in some cases
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/76260
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/76261
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/76261
This patch introduces the runtime components of a type sanitizer: a sanitizer
for type-based aliasing violations.
C/C++ have type-based aliasing rules, and LLVM's optimizer can exploit these
given TBAA metadata
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/76260
This patch introduces the runtime components of a type sanitizer: a sanitizer
for type-based aliasing violations.
C/C++ have type-based aliasing rules, and LLVM's optimizer can exploit these
given TBAA metadata
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/73553
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
fhahn wrote:
Thanks for all the feedback. I created #75527 which uses the approach based on
https://gist.github.com/fhahn/67937125b64440a8a414909c4a1b7973 with the tweak
suggested by @efriedma-quic
https://github.com/llvm/llvm-project/pull/73553
fhahn wrote:
> Just looked at https://gist.github.com/fhahn/67937125b64440a8a414909c4a1b7973
> ; that seems roughly appropriate. It's a little ugly to set the bit to false,
> then set it back to true, though; I'd rather just explicitly check whether
> all return instructions are
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/74761
>From 6ec44342b09474536d98de55238ee59452c06518 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Fri, 8 Dec 2023 11:00:17 +
Subject: [PATCH] for -> of
Created using spr 1.3.4
---
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/74761
>From 6ec44342b09474536d98de55238ee59452c06518 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Fri, 8 Dec 2023 11:00:17 +
Subject: [PATCH] for -> of
Created using spr 1.3.4
---
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/74761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/74761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/74761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1168,13 +1166,26 @@ class VPInstruction : public VPRecipeWithIRFlags,
public VPValue {
return false;
case VPInstruction::ActiveLaneMask:
case VPInstruction::CalculateTripCountMinusVF:
-case VPInstruction::CanonicalIVIncrement:
case
@@ -2624,6 +2644,9 @@ class VPlan {
/// The vector trip count.
VPValue () { return VectorTripCount; }
+ /// Returns runtime VF * UF for the vector loop region.
fhahn wrote:
Done, thanks!
https://github.com/llvm/llvm-project/pull/74761
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/74761
>From 6ec44342b09474536d98de55238ee59452c06518 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Fri, 8 Dec 2023 11:00:17 +
Subject: [PATCH] for -> of
Created using spr 1.3.4
---
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/74761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/74761
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/74761
This patch starts initial modeling of runtime VF * UF in VPlan.
Initially, introduce a dedicated RuntimeVFxUF VPValue, which is then
populated during VPlan::prepareToExecute. Initially, the runtime
VF * UF applies
fhahn wrote:
@kparzysz please take a loo at
https://gist.github.com/fhahn/67937125b64440a8a414909c4a1b7973, which has much
more limited impact.
> I haven't looked at the updated testcases in detail, but I see that most of
> the changes are in treating LR as live (whereas it was dead
fhahn wrote:
> I haven't looked closely to the patch, but I share @MatzeB's concerns here.
>
> Essentially this patch is reverting https://reviews.llvm.org/D36160, which
> was fixing a modeling issue with LR on ARM to begin with!
Thanks for sharing the additional context and where
fhahn wrote:
> I still feel like I am missing something here, and it's been a while since I
> looked at this. But my impression is that LLVM modeling is "cheating" a bit
> in that technically all the callee-saves should be implicit-uses of the
> return instruction (and not live afterwards)
Author: Florian Hahn
Date: 2023-11-27T19:15:33Z
New Revision: e59b116dbc7bf501016c7c68f348c39df8f598a8
URL:
https://github.com/llvm/llvm-project/commit/e59b116dbc7bf501016c7c68f348c39df8f598a8
DIFF:
https://github.com/llvm/llvm-project/commit/e59b116dbc7bf501016c7c68f348c39df8f598a8.diff
LOG:
fhahn wrote:
> Is this about computing **live-outs** of the return block as the code
> suggests? (The summary currently talks about live-ins?)
Thanks, it should be **live-outs** in the description, updated!
> I don't remember the situation on aarch64, but if by chance LR is modeled
> with
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/73553
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/fhahn edited https://github.com/llvm/llvm-project/pull/73553
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
=?utf-8?q?Balázs_Kéri?= ,
Endre =?utf-8?q?Fülöp?= ,Michael
Buch ,Momchil Velikov ,S.
B. Tam =?utf-8?q?,?=Matthew Devereau
,QuietMisdreavus
,Anatoly Trosinenko
,Diana ,Akash
Banerjee ,Ivan Kosarev ,Simon
Pilgrim ,Benjamin Maxwell
,Simon
Pilgrim ,David Sherwood
=?utf-8?q?Balázs_Kéri?= ,
Endre =?utf-8?q?Fülöp?= ,Michael
Buch ,Momchil Velikov ,S.
B. Tam =?utf-8?q?,?=Matthew Devereau
,QuietMisdreavus
,Anatoly Trosinenko
,Diana ,Akash
Banerjee ,Ivan Kosarev ,Simon
Pilgrim ,Benjamin Maxwell
,Simon
Pilgrim ,David Sherwood
Author: Florian Hahn
Date: 2023-11-17T12:52:05Z
New Revision: e3c1a20a1b5a115a75d83f5783ba64927607f427
URL:
https://github.com/llvm/llvm-project/commit/e3c1a20a1b5a115a75d83f5783ba64927607f427
DIFF:
https://github.com/llvm/llvm-project/commit/e3c1a20a1b5a115a75d83f5783ba64927607f427.diff
LOG:
Author: Florian Hahn
Date: 2023-11-17T12:52:06Z
New Revision: 1f729e0bc7a7012fa3a7618100f0865e4e32fc0d
URL:
https://github.com/llvm/llvm-project/commit/1f729e0bc7a7012fa3a7618100f0865e4e32fc0d
DIFF:
https://github.com/llvm/llvm-project/commit/1f729e0bc7a7012fa3a7618100f0865e4e32fc0d.diff
LOG:
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/72567
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Florian Hahn
Date: 2023-11-16T21:17:10Z
New Revision: 6f3b88baa2ac9ec892ed3ad7dd64d0d537010bc5
URL:
https://github.com/llvm/llvm-project/commit/6f3b88baa2ac9ec892ed3ad7dd64d0d537010bc5
DIFF:
https://github.com/llvm/llvm-project/commit/6f3b88baa2ac9ec892ed3ad7dd64d0d537010bc5.diff
LOG:
fhahn wrote:
The specific test cases came from some users who explicitly wanted to get the
code there if-converted for the CPU they are targeting. It may not be
profitable for all targets/CPUs though, so we would still rely on the
cost-model to take the correct decision per target/CPU.
fhahn wrote:
> Is the idea here that if the original code executed these unconditionally,
> then it's more likely than not that unconditionally executing them is
> beneficial?
I think the main motivation for the patch is the hypothesis that sinking early
is worse as canonical form early
fhahn wrote:
The reason for keeping the original `EnableCodeSinking` option is to retain the
ability to disable code sinking from the command line
https://github.com/llvm/llvm-project/pull/72567
___
llvm-branch-commits mailing list
https://github.com/fhahn created https://github.com/llvm/llvm-project/pull/72567
Sinking instructions very early in the pipeline destroys
dereferenceability information, that could be used by other passes, e.g.
this can prevent if-conversion by SimplifyCFG.
Author: Florian Hahn
Date: 2023-11-16T20:49:01Z
New Revision: 267d656ea58a77622dc512093bf64f50e4a04b95
URL:
https://github.com/llvm/llvm-project/commit/267d656ea58a77622dc512093bf64f50e4a04b95
DIFF:
https://github.com/llvm/llvm-project/commit/267d656ea58a77622dc512093bf64f50e4a04b95.diff
LOG:
Author: Florian Hahn
Date: 2023-11-16T20:48:54Z
New Revision: e8304de86f59fa66bc8af03b401b0c4d28f2ac97
URL:
https://github.com/llvm/llvm-project/commit/e8304de86f59fa66bc8af03b401b0c4d28f2ac97
DIFF:
https://github.com/llvm/llvm-project/commit/e8304de86f59fa66bc8af03b401b0c4d28f2ac97.diff
LOG:
1 - 100 of 228 matches
Mail list logo
