https://github.com/jrtc27 approved this pull request.
This should be low risk. If the condition holds, it would previously
dereference an invalid iterator, and either crash immediately thanks to
assertions or use whatever junk's in memory. Now it will treat it the same as
if there's an immedia
jrtc27 wrote:
As the author of the patch that seems sensible to me, and I’ve not been aware
of any regressions from it in main.
https://github.com/llvm/llvm-project/pull/113052
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
ht
@@ -361,6 +414,16 @@ class DataLayout {
return PTy && isNonIntegralPointerType(PTy);
}
+ bool shouldAvoidPtrToInt(Type *Ty) const {
+auto *PTy = dyn_cast(Ty);
+return PTy && shouldAvoidPtrToInt(PTy->getPointerAddressSpace());
jrtc27 wrote:
It s
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -419,9 +420,24 @@ Error DataLayout::parsePointerSpec(StringRef Spec) {
// Address space. Optional, defaults to 0.
unsigned AddrSpace = 0;
- if (!Components[0].empty())
-if (Error Err = parseAddrSpace(Components[0], AddrSpace))
+ bool UnstableRepr = false;
+ bool
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -342,14 +346,63 @@ class DataLayout {
SmallVector getNonIntegralAddressSpaces() const {
jrtc27 wrote:
This name seems stale given it's including unstable pointers
https://github.com/llvm/llvm-project/pull/105735
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -3082,16 +3129,21 @@ as follows:
``A``
Specifies the address space of objects created by '``alloca``'.
Defaults to the default address space of 0.
-``p[n]::[:][:]``
+``p[][]::[:][:]``
This specifies the *size* of a pointer and its and
\erred alignm
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
@@ -342,14 +346,63 @@ class DataLayout {
SmallVector getNonIntegralAddressSpaces() const {
SmallVector AddrSpaces;
for (const PointerSpec &PS : PointerSpecs) {
- if (PS.IsNonIntegral)
+ if (PS.HasNonIntegralRepresentation || PS.HasUnstableRepresentation)
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/113732
We've already called EnforceInteger on Types[0], and iPTRAny isn't
regarded as an integer type (note that TableGen special-cases iPTR here
to include that, though), so we cannot possibly still have an iPTRAny by
t
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/113732
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/113732
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/113733
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/113733
___
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/jrtc27 created
https://github.com/llvm/llvm-project/pull/113733
Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(wi
@@ -18,6 +18,6 @@
.globl _start
_start:
.data
- .word foo@PLT - .
- .word foo@PLT - . + 1
- .word foo@PLT - . - 1
+ .word %plt(foo - .)
jrtc27 wrote:
We have %(got_)pcrel_hi and now %gotpcrel, what's so different about this one?
https://github.com/llvm/ll
@@ -18,6 +18,6 @@
.globl _start
_start:
.data
- .word foo@PLT - .
- .word foo@PLT - . + 1
- .word foo@PLT - . - 1
+ .word %plt(foo - .)
jrtc27 wrote:
I've not looked at the implementation in detail, but thank you for taking the
time to do so, I know from
jrtc27 wrote:
The canonical PLT is for
```int main(void) {
return compare(&ifp);
}```
in code models where the address is computed inline (absolute or PC-relative)
rather than as an indirect load (whether from a global or a GOT entry).
I like to think of canonical PLTs as the function version
@@ -18,6 +18,6 @@
.globl _start
_start:
.data
- .word foo@PLT - .
- .word foo@PLT - . + 1
- .word foo@PLT - . - 1
+ .word %plt(foo - .)
jrtc27 wrote:
Yeah, I know, but it's pretty weird and confusing syntax. It's not really
written that way because it mak
@@ -18,6 +18,6 @@
.globl _start
_start:
.data
- .word foo@PLT - .
- .word foo@PLT - . + 1
- .word foo@PLT - . - 1
+ .word %plt(foo - .)
jrtc27 wrote:
Would `%plt(foo) - .` not be the saner syntax? PLT of an offset is a bit
nonsensical...
https://github.c
@@ -18,6 +18,6 @@
.globl _start
_start:
.data
- .word foo@PLT - .
- .word foo@PLT - . + 1
- .word foo@PLT - . - 1
+ .word %plt(foo - .)
jrtc27 wrote:
Well my overarching point would be that user-facing syntax should not be
beholden to arbitrary historic i
@@ -4274,6 +4274,7 @@ bool LLParser::parseValID(ValID &ID, PerFunctionState
*PFS, Type *ExpectedTy) {
case lltok::kw_bitcast:
case lltok::kw_addrspacecast:
case lltok::kw_inttoptr:
+ // ptrtoaddr not supported in constant exprs (yet?).
jrtc27 wrote:
(i
@@ -4274,6 +4274,7 @@ bool LLParser::parseValID(ValID &ID, PerFunctionState
*PFS, Type *ExpectedTy) {
case lltok::kw_bitcast:
case lltok::kw_addrspacecast:
case lltok::kw_inttoptr:
+ // ptrtoaddr not supported in constant exprs (yet?).
jrtc27 wrote:
Th
@@ -1583,6 +1583,26 @@ bool IRTranslator::translateCast(unsigned Opcode, const
User &U,
return true;
}
+bool IRTranslator::translatePtrToAddr(const User &U,
+ MachineIRBuilder &MIRBuilder) {
+ if (containsBF16Type(U))
+return false;
@@ -650,48 +650,136 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
jrtc27 wrote:
> Thanks for cleaning up my ugly https://reviews.llvm.org/D100490 in the
> previous commits :)
>
> I think having names for the boolean parameters makes the code calling this
> function easier to read than a magic true/false. So I'd have a slight
> preference for keeping an enum
jrtc27 wrote:
> Is this the last change in the patch series? The use of booleans is a good
> move to prevent the complexity of MIPS-style dynamic relocations (which I
> haven’t fully analyzed). Thanks for tidying this up!
Yes, though #150729 and #150730 are based on this patch series (as a
lo
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/150798
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150798
___
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/jrtc27 created
https://github.com/llvm/llvm-project/pull/150799
Currently we set the kind to AddendOnly in computeRaw() in order to
catch cases where we're not treating the DynamicReloc as computed.
Specifically, computeAddend() will then assert that sym is nullptr, so
can cat
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150797
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150797
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150729
>From 32400cb0d5c16e16b6d0d259955ba060f561fefe Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 02:12:18 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?U
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/150729
___
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/jrtc27 edited
https://github.com/llvm/llvm-project/pull/150729
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
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/jrtc27 created
https://github.com/llvm/llvm-project/pull/150798
The former is just a special case of the latter, ignoring the expr and
always just using the addend. If we use R_ADDEND as expr (which
previously had no effect, and so was misleadingly R_ABS not R_ADDEND in
all bu
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150797
The former is just a special case of the latter, ignoring the expr and
always just using the addend, allowing (and enforcing) the sym is null.
If we just use dummySym then we don't need to maintain this as a
separ
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150795
The former is just a special case of the latter, ignoring the expr and
always just using the addend. If we use R_ADDEND as expr (which
previously had no effect, and so was misleadingly R_ABS not R_ADDEND in
all bu
https://github.com/jrtc27 closed
https://github.com/llvm/llvm-project/pull/150795
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jrtc27 wrote:
#150798. Screwed up spr...
https://github.com/llvm/llvm-project/pull/150795
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jrtc27 wrote:
> When DynamicReloc::Kind was introduced, I was concerned of the many Kinds,
> but that was still better than the previous state. Thanks for the
> simplification.
Yeah I think Alex was a bit confused (and also there were some bugs that he
faithfully replicated and since fixed, o
jrtc27 wrote:
> > The current code is quite crusty and divergent from non-MIPS in API use,
> > but fixing it up like this is quite high-risk, especially given how weird
> > the MIPS GOT is when it comes to the required initial memory state. Is
> > anyone using LLD for MIPS these days who can t
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150810
Instead of having a special DynamicReloc::Kind, we can just use a new
RelExpr for the calculation needed. The only odd thing we do that allows
this is to keep a representative symbol for the OutputSection in
quest
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150811
This second constructor is just a shorthand for an AddendOnly relocation
against dummySym with R_ADDEND, so write it as such.
___
llvm-branch-commits mailing list
llv
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150812
Aside from Computed, Kind is now just AddendOnly and AgainstSymbol, so
it's really just a bool reflecting whether the resulting ELF relocation
should reference the symbol or not. Refactor DynamicReloc's storage to
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150798
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150729
>From 32400cb0d5c16e16b6d0d259955ba060f561fefe Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 02:12:18 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?U
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150729
>From 32400cb0d5c16e16b6d0d259955ba060f561fefe Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 02:12:18 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?U
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150813
DynamicReloc::AgainstSymbol is now true and DynamicReloc::AddendOnly is
now false; uses of the constants were replaced mechanically.
___
llvm-branch-commits mailing l
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/150730
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jrtc27 wrote:
NB: This is a transient state, https://github.com/llvm/llvm-project/pull/150812
removes this member. This makes the history a bit odd, but I think it makes it
clearer what's going on to include this in the history.
https://github.com/llvm/llvm-project/pull/150799
jrtc27 wrote:
> > When DynamicReloc::Kind was introduced, I was concerned of the many Kinds,
> > but that was still better than the previous state. Thanks for the
> > simplification.
>
> Yeah I think Alex was a bit confused (and also there were some bugs that he
> faithfully replicated and si
jrtc27 wrote:
The current code is quite crusty and divergent from non-MIPS in API use, but
fixing it up like this is quite high-risk, especially given how weird the MIPS
GOT is when it comes to the required initial memory state. Is anyone using LLD
for MIPS these days who can test this in a wi
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/150730
Splitting the VA / addend calculations between build and writeTo means
having to keep them in sync and duplicating some of the logic. For
everything except "page address" relocations, move all such calculations
in
@@ -1055,74 +1059,122 @@ void MipsGotSection::build() {
ctx.symAux.back().gotIdx = p.second;
}
- // Create dynamic relocations.
+ // Create relocations.
+ //
+ // NB: GOT 'page address' entries have their VAs handled in writeTo as they
+ // reference an OutputSectio
@@ -2139,17 +2139,44 @@ void ThunkCreator::mergeThunks(ArrayRef outputSections) {
});
}
-static int64_t getPCBias(Ctx &ctx, RelType type) {
- if (ctx.arg.emachine != EM_ARM)
-return 0;
- switch (type) {
- case R_ARM_THM_JUMP19:
- case R_ARM_THM_JUMP24:
- case R_
jrtc27 wrote:
/cherry-pick b03d1e1e2e8e4b0b4b9e035b7ad9fb86dccefb93
de15d365743e16848a9d15fc32ae6ab98d399ec2
723b40a8d92f76fc913ef21061fc3d74e8c47441
https://github.com/llvm/llvm-project/pull/149723
___
llvm-branch-commits mailing list
llvm-branch-co
@@ -2139,17 +2139,44 @@ void ThunkCreator::mergeThunks(ArrayRef outputSections) {
});
}
-static int64_t getPCBias(Ctx &ctx, RelType type) {
- if (ctx.arg.emachine != EM_ARM)
-return 0;
- switch (type) {
- case R_ARM_THM_JUMP19:
- case R_ARM_THM_JUMP24:
- case R_
jrtc27 wrote:
> ```
> /builddir/build/BUILD/llvm-21.1.0_rc2-build/llvm-project-21.1.0-rc2.src/lld/test/ELF/hexagon-thunks-packets.s:20:17:
> error: CHECK-NONPIC: expected string not found i
> n input
> # CHECK-NONPIC: jump 0x1020110 }
> ^
> :7:50: note: scanning from here
> 200
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150798
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150810
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150810
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150811
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150811
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150812
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150813
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150812
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150813
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150799
>From 1308e1aad30d7089f658832150854b1362c63f45 Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 22:05:06 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20change?=
=?U
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150797
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150797
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150729
>From 32400cb0d5c16e16b6d0d259955ba060f561fefe Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 02:12:18 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?U
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150729
>From 32400cb0d5c16e16b6d0d259955ba060f561fefe Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Sat, 26 Jul 2025 02:12:18 +0100
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?U
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
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/jrtc27 updated
https://github.com/llvm/llvm-project/pull/150730
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jrtc27 wrote:
> > It's indeed very difficult to find folks still concerned with MIPS... I
> > believe only one company is still actively contributing to the MIPS backend
> > in LLVM... @wzssyqa
> > Besides the ClangBuiltLinux maintainer and the OpenBSD maintainer continue
> > to support MIPS.
@@ -422,13 +422,10 @@ class DynamicReloc {
/// The resulting dynamic relocation has already had its addend computed.
/// Calling computeAddend() is an error. Only for internal use.
Computed,
-/// The resulting dynamic relocation does not reference a symbol (#sym
@@ -2627,6 +2629,93 @@ SDValue DAGCombiner::foldSubToAvg(SDNode *N, const SDLoc
&DL) {
return SDValue();
}
+/// Try to fold a pointer arithmetic node.
+/// This needs to be done separately from normal addition, because pointer
+/// addition is not commutative.
+SDValue DAGC
jrtc27 wrote:
> isNullConstant(X), since there are address spaces where 0 is a perfectly
normal value that shouldn't be treated specially,
I don't know if it's important for CHERI to have this or if the IR-level
optimisations render it not so needed. But `NULL + int` is how we represent an
int
jrtc27 wrote:
Ping
https://github.com/llvm/llvm-project/pull/150729
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
94 matches
Mail list logo
