https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/5] [clang] Strict aliasing warning ala GCC [PR50066]
This imp
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
@@ -2026,6 +2027,137 @@ static TryCastResult TryConstCast(Sema &Self,
ExprResult &SrcExpr,
return TC_Success;
}
+// We're dereferencing E, either by turning into an RValue, or by dereferencing
+// it. Check whether it's a deref of a reinterpret cast that has aliasing
+// is
urnathan wrote:
> Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> violation (and probably breaks if we aren't actually generating code). If we
> need some notion of "aliasing" in Sema, we should pull the relevant code into
> clang/lib/AST.
That's unfortunate. The code
urnathan wrote:
> FWIW the GCC doc is
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> It says for Level 3 "If optimization is enabled, it also runs in the back
> end, where it deals with multiple statement cases using flow-sensitive
> points-to informa
urnathan wrote:
> Thank you for your efforts! I scratched the surface a bit; not qualified to
> do an in-depth review. Can you also add a release note?
Thanks for your comments. A release note is added.
https://github.com/llvm/llvm-project/pull/74155
__
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -128,6 +128,10 @@ class DiagnosticOptions : public
RefCountedBase{
/// whether -Wsystem-headers is enabled on a per-module basis.
std::vector SystemHeaderWarningsModules;
+ /// Level of scrutiny reinterpret_casts get for type-unsafe aliasing
+ /// checks. Requires an
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/6] [clang] Strict aliasing warning ala GCC [PR50066]
This imp
@@ -0,0 +1,192 @@
+// RUN: %clang_cc1 %s -O0 -Wstrict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=0 -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wno-strict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=1 -S -o %
urnathan wrote:
> I'm planning to take a closer look at this when I have more time. Sorry I
> haven't been more responsive here.
When might that be?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/74893
An 8 bit bitfield with preferred bool type? Seems confused.
>From f7cac332123f6ea6c78dcffbcac2d58f356b6396 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 8 Dec 2023 17:43:22 -0500
Subject: [PATCH] [cl
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/74893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/74893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
Rebased
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> I'd tend to prefer to keep the simpler name for the external interface, and
> use a more complicated one for use within the class. So maybe introduce
> getValidBaseTypeInfo().
This naming scheme better?
https://github.com/llvm/llvm-project/pull/73263
urnathan wrote:
thanks @yonghong-song!
Taking the opportunity for a ping :)
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
I'm going to break this apart, as I've realized this has conflated two separate
problems.
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/69739
>From bb391aa466577f4187af6b284ee5107090778a03 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 20 Oct 2023 11:43:08 -0400
Subject: [PATCH 1/2] [clang] Robustify open mp test
If the source path contains
urnathan wrote:
@jdoerfert thanks for that, here's an update that focusses the check-not more
precisely.
https://github.com/llvm/llvm-project/pull/69739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/70149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/69739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> One very brief note: in the comments in the code, you might want to
> distinguish between the semantic width of a bitfield (i.e. the C standard
> notion of a "memory location", which has ABI significance), vs. the accesses
> we choose to generate (we don't need to generate n
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/71170
With Fedora 39, I encountered 2 new python warnings:
/home/nathan/gh/llvm/push/strict-aliasing/clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py:28:
SyntaxWarning: invalid escape sequence '\*'
self.implemen
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/71170
>From 9b5cb1ac8d4b9a2aaa4c06e41620e38b6c3cae8c Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 2 Nov 2023 18:14:05 -0400
Subject: [PATCH 1/2] Fix python escapes
With Fedora 39, I encountered 2 new pyth
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/71170
>From 9b5cb1ac8d4b9a2aaa4c06e41620e38b6c3cae8c Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 2 Nov 2023 18:14:05 -0400
Subject: [PATCH 1/3] Fix python escapes
With Fedora 39, I encountered 2 new pyth
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -37,6 +38,27 @@ class ASTConsumer {
friend class SemaConsumer;
+public:
+ /// Allow type-based aliasing information to be interrogated by the AST
+ /// producer (for diagnostics).
+ class TypeAliasing {
urnathan wrote:
Oh, we also endup deriving from
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
+CodeGenTBAA::A
urnathan wrote:
> > > FWIW the GCC doc is
> > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> > > It says for Level 3 "If optimization is enabled, it also runs in the
> > > back end, where it deals with multiple statement cases using
> > > flow-sensiti
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/73263
I noticed a couple of minor issues with CodeGenTBAA::getBaseTypeInfo.
1) isValidBaseType explicitly checks for a reference type to return false, but
then also returns false for all non-record types. Just remove
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/73264
I noticed that TBAA BaseTypeMetadataCache can legitimately store null values,
but it also uses that to mean 'no entry'. Thus nullptr entries get continually
recalculated. (AFAICT null entries can never become n
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/73264
>From e4c92cd687782743ba939becf7ea8862eea6a108 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 23 Nov 2023 11:30:12 -0500
Subject: [PATCH 1/2] [clang] Avoid recalculating TBAA base type info
I noticed
@@ -418,14 +418,20 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfo(QualType QTy) {
return nullptr;
const Type *Ty = Context.getCanonicalType(QTy).getTypePtr();
- if (llvm::MDNode *N = BaseTypeMetadataCache[Ty])
-return N;
- // Note that the following helper call is
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/73263
>From 2a312ddadae91ea52b184edaa0d19495c6e0f4a3 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 22 Nov 2023 20:45:38 -0500
Subject: [PATCH 1/2] [clang][NFC] Adjust TBAA Base Info API
I noticed a couple
urnathan wrote:
sure, like so?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
You knew this ping was coming, right?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/74155
This implements -Wstrict-aliasing(=[123])? along the same lines as GCC. It's
not 100% the same for reasons expanded on below. The default is level 3, and I
have verified that bootstrapping does not trigger any
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
ping?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
ping?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
@efriedma-quic this naming ok?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
Can someone please review this?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -95,8 +95,6 @@ static bool TypeHasMayAlias(QualType QTy) {
/// Check if the given type is a valid base type to be used in access tags.
static bool isValidBaseType(QualType QTy) {
- if (QTy->isReferenceType())
-return false;
urnathan wrote:
This is cas
Author: Nathan Sidwell
Date: 2022-03-24T05:56:23-07:00
New Revision: de867c6d6ed86851dcd0f9de1154db3d42a0ad63
URL:
https://github.com/llvm/llvm-project/commit/de867c6d6ed86851dcd0f9de1154db3d42a0ad63
DIFF:
https://github.com/llvm/llvm-project/commit/de867c6d6ed86851dcd0f9de1154db3d42a0ad63.diff
Author: Nathan Sidwell
Date: 2022-03-30T08:51:27-07:00
New Revision: ae4dce8659f313ca2034782583d31993212fa8bd
URL:
https://github.com/llvm/llvm-project/commit/ae4dce8659f313ca2034782583d31993212fa8bd
DIFF:
https://github.com/llvm/llvm-project/commit/ae4dce8659f313ca2034782583d31993212fa8bd.diff
Author: Nathan Sidwell
Date: 2022-04-05T06:54:31-07:00
New Revision: 54c50336e4c11e9c9255d96ae0b55a56cc193ecb
URL:
https://github.com/llvm/llvm-project/commit/54c50336e4c11e9c9255d96ae0b55a56cc193ecb
DIFF:
https://github.com/llvm/llvm-project/commit/54c50336e4c11e9c9255d96ae0b55a56cc193ecb.diff
Author: Nathan Sidwell
Date: 2022-04-06T03:57:36-07:00
New Revision: ba4482f481991799a922d5cf124a56bea5866254
URL:
https://github.com/llvm/llvm-project/commit/ba4482f481991799a922d5cf124a56bea5866254
DIFF:
https://github.com/llvm/llvm-project/commit/ba4482f481991799a922d5cf124a56bea5866254.diff
Author: Nathan Sidwell
Date: 2022-04-06T11:13:32-07:00
New Revision: 482fad4a3fcb013aa19e97661e3d66583d026bb8
URL:
https://github.com/llvm/llvm-project/commit/482fad4a3fcb013aa19e97661e3d66583d026bb8
DIFF:
https://github.com/llvm/llvm-project/commit/482fad4a3fcb013aa19e97661e3d66583d026bb8.diff
Author: Nathan Sidwell
Date: 2022-04-07T05:40:57-07:00
New Revision: 9eda5fc0c6eafd772d0e6ff015352136c5e505a4
URL:
https://github.com/llvm/llvm-project/commit/9eda5fc0c6eafd772d0e6ff015352136c5e505a4
DIFF:
https://github.com/llvm/llvm-project/commit/9eda5fc0c6eafd772d0e6ff015352136c5e505a4.diff
Author: Nathan Sidwell
Date: 2022-02-10T04:44:48-08:00
New Revision: 815446cd3e164b8be010864648d4104ad178b129
URL:
https://github.com/llvm/llvm-project/commit/815446cd3e164b8be010864648d4104ad178b129
DIFF:
https://github.com/llvm/llvm-project/commit/815446cd3e164b8be010864648d4104ad178b129.diff
Author: Nathan Sidwell
Date: 2022-02-15T04:28:45-08:00
New Revision: 02093906fa0fd5bacc61b2189ea643c78cd02509
URL:
https://github.com/llvm/llvm-project/commit/02093906fa0fd5bacc61b2189ea643c78cd02509
DIFF:
https://github.com/llvm/llvm-project/commit/02093906fa0fd5bacc61b2189ea643c78cd02509.diff
Author: Nathan Sidwell
Date: 2022-02-16T04:30:47-08:00
New Revision: 082f328899be9ed8a38b04a4e52be936f4875495
URL:
https://github.com/llvm/llvm-project/commit/082f328899be9ed8a38b04a4e52be936f4875495
DIFF:
https://github.com/llvm/llvm-project/commit/082f328899be9ed8a38b04a4e52be936f4875495.diff
Author: Nathan Sidwell
Date: 2022-05-16T05:15:12-07:00
New Revision: 80bebbc7cb77979ef9d229450b7ea84e3e9c6a5a
URL:
https://github.com/llvm/llvm-project/commit/80bebbc7cb77979ef9d229450b7ea84e3e9c6a5a
DIFF:
https://github.com/llvm/llvm-project/commit/80bebbc7cb77979ef9d229450b7ea84e3e9c6a5a.diff
Author: Nathan Sidwell
Date: 2022-05-23T09:03:10-07:00
New Revision: a1dcfb75ea8c31dd39edb6bdab6f54cde81cad85
URL:
https://github.com/llvm/llvm-project/commit/a1dcfb75ea8c31dd39edb6bdab6f54cde81cad85
DIFF:
https://github.com/llvm/llvm-project/commit/a1dcfb75ea8c31dd39edb6bdab6f54cde81cad85.diff
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
urnathan wrote:
@rjmccall here is a rebase an update, which I think addresses all your
comments. I did make some material changes though:
1) I removed the Volatile handling. I was always a little uncomfortable with it
because it didn't affect the access units of a non-volatile bitfield that e
urnathan wrote:
Sorry to push another update, but I realized the LimitOffset computation could
be sunk to the point of use, and therefore not computed in all cases.
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commi
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
urnathan wrote:
@rjmccall thanks, here is an update with those changes. I've collapsed it to
the 3 commits mentioned earlier
1) Tests marked up for the current behaviour
2) TargetInfo strict/flexible alignment load predicate
3) The new algorithm
https://github.com/llvm/llvm-project/pull/65742
Author: Nathan Sidwell
Date: 2024-03-29T09:35:31-04:00
New Revision: a8ca4abfcfa98d28ec46ee497e1fc5e91f8e1ad6
URL:
https://github.com/llvm/llvm-project/commit/a8ca4abfcfa98d28ec46ee497e1fc5e91f8e1ad6
DIFF:
https://github.com/llvm/llvm-project/commit/a8ca4abfcfa98d28ec46ee497e1fc5e91f8e1ad6.diff
Author: Nathan Sidwell
Date: 2024-03-29T09:35:31-04:00
New Revision: 7df79ababee8d03b27bbaba1aabc2ec4ea14143e
URL:
https://github.com/llvm/llvm-project/commit/7df79ababee8d03b27bbaba1aabc2ec4ea14143e
DIFF:
https://github.com/llvm/llvm-project/commit/7df79ababee8d03b27bbaba1aabc2ec4ea14143e.diff
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
Committed, expect tailclipping cleanup PR soon
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/87090
This follows on from PR65742. As I suspected clipTailPadding's functionality
can be moved into accumulateBitfields; it has sufficient information now. It
turns out that clipTailPadding was undoing some of the
urnathan wrote:
Sigh, clipTailPadding is still needed, because of no_unique_address and empty
base placement. Will update.
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
urnathan wrote:
#65742 is committed, so MIPS' TargetInfo will need adjusting to propagate the
unaligned capability. See 7df79ababee8
https://github.com/llvm/llvm-project/pull/85174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/87238
This fixes #87227 My change to bitfield access unit allocation (#65742) causes
an ICE for a corner case of vbase allocation: a class where an unshared (i.e.
not the nearly-empty base optimization) vbase is plac
https://github.com/urnathan converted_to_draft
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
Be aware of bug #87227 and PR #87238 to address that
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -330,6 +331,8 @@ class LLVM_LIBRARY_VISIBILITY MipsTargetInfo : public
TargetInfo {
IsMicromips = true;
else if (Feature == "+mips32r6" || Feature == "+mips64r6")
HasUnalignedAccess = true;
+ else if (Feature == "+strict-align")
+StrictAli
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> On the LLVM side, there's very little interesting logic; it's basically just
> walking the tree of metadata nodes generated by clang. See
> https://llvm.org/docs/LangRef.html#tbaa-node-semantics . The hard part of the
> refactoring would just be adding an abstraction for the
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
urnathan wrote:
This update
* moves the creation and installation of the BitFieldAccessUnit objects into
CGRecordLowering.
* adds aarch64 and arm darwin target tests, as those have different layout
rules (let me know if I've missed something here).
* Simplifies the checking of barriers -- an e
urnathan wrote:
@rjmccall here's a refactoring along the lines you suggested. Once one stops
worrying about rescanning when the next access unit fails to accumulate into
the current one, things get simpler. The compiler should be able to turn the
boolean conditional flow within the loop body i
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/82874
As mentioned in PR https://github.com/llvm/llvm-project/pull/65742, these
functions do not alter the object -- and on one case don't even need it. Thus
marking them static or const as appropriate. I constified
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/82874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Nathan Sidwell
Date: 2024-02-24T12:25:08-05:00
New Revision: 8e22fffc85b36784146041499b716cec74285660
URL:
https://github.com/llvm/llvm-project/commit/8e22fffc85b36784146041499b716cec74285660
DIFF:
https://github.com/llvm/llvm-project/commit/8e22fffc85b36784146041499b716cec74285660.diff
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/82874
>From 792c608cc55d89552cf86d058796825a1f428f5d Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 2 Feb 2024 08:01:21 -0500
Subject: [PATCH] [clang][NFC] constify or staticify some fns
These functions do
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/82874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -132,6 +132,7 @@ class LLVM_LIBRARY_VISIBILITY LoongArch64TargetInfo
: LoongArchTargetInfo(Triple, Opts) {
LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
IntMaxType = Int64Type = SignedLong;
+HasCheapUnalignedBitfieldAccess = true;
--
urnathan wrote:
> Yeah, LLVM supports changing subtarget options on a per-function basis. We
> would presumably make the query based on the global setting.
>
> Anyway, getting this information from LLVM doesn't seem tractable in the
> short-to-medium term; it's just unfortunate.
Thinking furt
urnathan wrote:
> >
>
> Thinking further, several (AArch64, ARM & Loongson) targets have a
> 'HasUnaligned' bool in their TargetInfo objects. Perhaps the way forwards is
> to promote that to the base TargetInfo and just use that, rather than the
> bitfield-specific field I added (which just
urnathan wrote:
@rjmccall thanks for your comments. Here's a reimplementation using a single
loop -- the downside is that we may end up repeating the initial grouping scan,
if we search more than 1 Access Unit ahead and fail to find a 'good' access
unit. This update changes the algorithm sli
@@ -376,33 +377,41 @@ void CGRecordLowering::lowerUnion(bool isNoUniqueAddress)
{
}
void CGRecordLowering::accumulateFields() {
- for (RecordDecl::field_iterator Field = D->field_begin(),
- FieldEnd = D->field_end();
-Field != FieldEnd;)
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/69739
If the source path contains 'alias' this would spuriously fail. Be more
specific about not wanting [no]alias annotations.
>From bb391aa466577f4187af6b284ee5107090778a03 Mon Sep 17 00:00:00 2001
From: Nathan Si
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/69739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 192 matches
Mail list logo
