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:
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:
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
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:
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:
> 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:
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
@@ -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:
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 "
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: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: 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: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: 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-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: 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
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
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
19 matches
Mail list logo
