https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/126027
___
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/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/126030
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jyknight wrote:
> The tests posted in the review work from that point on, except [...]
Sure, I agree that the tests which have been added pass. But the tests do not
currently test everything necessary for this feature to be complete.
What I see here is a series of PRs each adding some part of
jyknight wrote:
> At this PR, this is the expectation. A later PR needs to handle the other
> vector legalization cases
Well, it also doesn't work after the rest of the series.
As a general comment, I find it difficult to review a series of PRs where the
intermediate state between them is bro
@@ -2595,6 +2595,10 @@ X86TargetLowering::X86TargetLowering(const
X86TargetMachine &TM,
setOperationAction(Op, MVT::f32, Promote);
}
+ setOperationPromotedToType(ISD::ATOMIC_LOAD, MVT::f16, MVT::i16);
jyknight wrote:
Presumably similar changes to
jyknight wrote:
> Atomic vectors with size >1 are lowered to calls.
That's not true; they're only lowered to calls when the alignment is not known
to be sufficient (e.g. `<2 x i32>` must have `align 8`, not `align 4`).
https://github.com/llvm/llvm-project/pull/120387
__
jyknight wrote:
Running `llc -mtriple=x86_64-linux-gnu` on
```
define <2 x i32> @atomic_vec2_i32(ptr %x) #0 {
%ret = load atomic <2 x i32>, ptr %x acquire, align 64
ret <2 x i32> %ret
}
```
crashes with:
```
WidenVectorResult #0: t3: v2i32,ch = AtomicLoad<(load acquire (s64) from %ir.x,
alig
jyknight wrote:
This sounds sketchy to me. Is it really valid to enter a second call inside
another call's CALLSEQ markers, but only if we avoid adding a second nested set
of markers? It feels like attacking the symptom of the issue, but not the root
cause. (I'm not certain it's _not_ valid, b
jyknight wrote:
In particular, I think it would be incorrect to just look at floating-point
operations at the MIR level, because calling printf with a constant floating
point argument doesn't necessarily use any floating point instructions.
https://github.com/llvm/llvm-project/pull/100368
jyknight wrote:
It's been a while since I looked at this, but its purpose, at least back then
(2c36240a820c27450c0626a7161646e2d20d3f6d) is very different than what was
discussed above.
It had two effects:
1. decide whether to include floating-point support in printf/scanf library
routines.
jyknight wrote:
So the problem Rust sees isn't that a ".1" was added to the version, but rather
that the name was changed from "libLLVM-18-rust-1.78.0-nightly.so" to
"libLLVM.so.18.1-rust-1.78.0-nightly". (that is: all the version info
previously went into the library name which comes before "
@@ -1436,6 +1436,8 @@ static void readConfigs(opt::InputArgList &args) {
config->zInterpose = hasZOption(args, "interpose");
config->zKeepTextSectionPrefix = getZFlag(
args, "keep-text-section-prefix", "nokeep-text-section-prefix", false);
+ config->zLrodataAfterBss
@@ -1436,6 +1436,8 @@ static void readConfigs(opt::InputArgList &args) {
config->zInterpose = hasZOption(args, "interpose");
config->zKeepTextSectionPrefix = getZFlag(
args, "keep-text-section-prefix", "nokeep-text-section-prefix", false);
+ config->zLrodataAfterBss
jyknight wrote:
Do we need this backported, given that the triggering commit isn't going to be
backported?
https://github.com/llvm/llvm-project/pull/81713
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/c
jyknight wrote:
> I don't think this means that we unsupport -no-pie use cases
Yes, we'd still support -no-pie, but we'd fail to support -no-pie
-mcmodel=medium.
> cost of layout purity
I see that you feel strongly about this (e.g. by calling it "purity"), but I
don't understand why. It's no
jyknight wrote:
I don't follow.
no-pie is _uncommon_ but not _unsupported_. Making users add a linker script
when they wouldn't otherwise have one, in order to have a working no-pie build
seems unjustified.
https://github.com/llvm/llvm-project/pull/81224
__
jyknight wrote:
ISTM that making the layout conditional in order to not regress the most-common
case (PIE) would be worth a minor amount of code in lld, even though the
benefit is also relatively small.
Do you think INSERT scripts are going to be a real-world issue there? It seems
to me like
jyknight wrote:
Why not condition this on `-no-pic`, and keep the previous more-optimal layout
for the normal case?
https://github.com/llvm/llvm-project/pull/81224
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.l
Author: James Y Knight
Date: 2022-02-08T17:16:19-05:00
New Revision: 241275a01ed88cd59d503449a8c74a3b7cfedbb2
URL:
https://github.com/llvm/llvm-project/commit/241275a01ed88cd59d503449a8c74a3b7cfedbb2
DIFF:
https://github.com/llvm/llvm-project/commit/241275a01ed88cd59d503449a8c74a3b7cfedbb2.diff
Author: James Y Knight
Date: 2021-01-27T20:02:30-05:00
New Revision: 0b7b698fecd37415a635a586e5ca159ab0b8872f
URL:
https://github.com/llvm/llvm-project/commit/0b7b698fecd37415a635a586e5ca159ab0b8872f
DIFF:
https://github.com/llvm/llvm-project/commit/0b7b698fecd37415a635a586e5ca159ab0b8872f.diff
Author: James Y Knight
Date: 2021-01-27T20:02:30-05:00
New Revision: 7da92afbf08e90960f7e5dee00bbf6ef8f323a5c
URL:
https://github.com/llvm/llvm-project/commit/7da92afbf08e90960f7e5dee00bbf6ef8f323a5c
DIFF:
https://github.com/llvm/llvm-project/commit/7da92afbf08e90960f7e5dee00bbf6ef8f323a5c.diff
Author: James Y Knight
Date: 2021-01-27T20:02:29-05:00
New Revision: b0085d205b3063c332a080599830ef0500cb6924
URL:
https://github.com/llvm/llvm-project/commit/b0085d205b3063c332a080599830ef0500cb6924
DIFF:
https://github.com/llvm/llvm-project/commit/b0085d205b3063c332a080599830ef0500cb6924.diff
Author: James Y Knight
Date: 2020-12-29T16:18:10-05:00
New Revision: 145cbef5879c7fba8bacc2f78cfa426400f52f42
URL:
https://github.com/llvm/llvm-project/commit/145cbef5879c7fba8bacc2f78cfa426400f52f42
DIFF:
https://github.com/llvm/llvm-project/commit/145cbef5879c7fba8bacc2f78cfa426400f52f42.diff
Author: James Y Knight
Date: 2020-12-28T18:11:17-05:00
New Revision: 4ddf140c00408ecee9d20f4470e69e0f696d8f8a
URL:
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a
DIFF:
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a.diff
Author: James Y Knight
Date: 2020-07-17T16:29:56-04:00
New Revision: 8a438096ffa48dadeb73b78844c53a7428aaec20
URL:
https://github.com/llvm/llvm-project/commit/8a438096ffa48dadeb73b78844c53a7428aaec20
DIFF:
https://github.com/llvm/llvm-project/commit/8a438096ffa48dadeb73b78844c53a7428aaec20.diff
Author: jyknight
Date: Thu Dec 20 15:48:45 2018
New Revision: 349860
URL: http://llvm.org/viewvc/llvm-project?rev=349860&view=rev
Log:
Remove old misnamed tag ("final" was created right afterwards).
Removed:
llvm/tags/RELEASE_351/Final/
___
llvm-br
26 matches
Mail list logo
