r350372 - Adopt SwiftABIInfo for WebAssembly.
Author: ddunbar
Date: Thu Jan 3 15:24:50 2019
New Revision: 350372
URL: http://llvm.org/viewvc/llvm-project?rev=350372&view=rev
Log:
Adopt SwiftABIInfo for WebAssembly.
Summary:
- This adopts SwiftABIInfo as the base class for WebAssemblyABIInfo, which is
in keeping with what is done for other targets for which Swift is supported.
- This is a minimal patch to unblock exploration of WASM support for Swift
(https://bugs.swift.org/browse/SR-9307)
Reviewers: rjmccall, sunfish
Reviewed By: rjmccall
Subscribers: ahti, dschuff, sbc100, jgravelle-google, aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D56188
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=350372&r1=350371&r2=350372&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jan 3 15:24:50 2019
@@ -720,10 +720,12 @@ ABIArgInfo DefaultABIInfo::classifyRetur
// This is a very simple ABI that relies a lot on DefaultABIInfo.
//===--===//
-class WebAssemblyABIInfo final : public DefaultABIInfo {
+class WebAssemblyABIInfo final : public SwiftABIInfo {
+ DefaultABIInfo defaultInfo;
+
public:
explicit WebAssemblyABIInfo(CodeGen::CodeGenTypes &CGT)
- : DefaultABIInfo(CGT) {}
+ : SwiftABIInfo(CGT), defaultInfo(CGT) {}
private:
ABIArgInfo classifyReturnType(QualType RetTy) const;
@@ -741,6 +743,15 @@ private:
Address EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
QualType Ty) const override;
+
+ bool shouldPassIndirectlyForSwift(ArrayRef scalars,
+bool asReturnValue) const override {
+return occupiesMoreThan(CGT, scalars, /*total*/ 4);
+ }
+
+ bool isSwiftErrorInRegister() const override {
+return false;
+ }
};
class WebAssemblyTargetCodeGenInfo final : public TargetCodeGenInfo {
@@ -778,7 +789,7 @@ ABIArgInfo WebAssemblyABIInfo::classifyA
}
// Otherwise just do the default thing.
- return DefaultABIInfo::classifyArgumentType(Ty);
+ return defaultInfo.classifyArgumentType(Ty);
}
ABIArgInfo WebAssemblyABIInfo::classifyReturnType(QualType RetTy) const {
@@ -798,7 +809,7 @@ ABIArgInfo WebAssemblyABIInfo::classifyR
}
// Otherwise just do the default thing.
- return DefaultABIInfo::classifyReturnType(RetTy);
+ return defaultInfo.classifyReturnType(RetTy);
}
Address WebAssemblyABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
@@ -8307,7 +8318,7 @@ ABIArgInfo ARCABIInfo::getIndirectByRef(
}
ABIArgInfo ARCABIInfo::getIndirectByValue(QualType Ty) const {
- // Compute the byval alignment.
+ // Compute the byval alignment.
const unsigned MinABIStackAlignInBytes = 4;
unsigned TypeAlign = getContext().getTypeAlign(Ty) / 8;
return ABIArgInfo::getIndirect(CharUnits::fromQuantity(4), /*ByVal=*/true,
@@ -8371,7 +8382,7 @@ ABIArgInfo ARCABIInfo::classifyReturnTyp
if (RetTy->isAnyComplexType())
return ABIArgInfo::getDirectInReg();
- // Arguments of size > 4 registers are indirect.
+ // Arguments of size > 4 registers are indirect.
auto RetSize = llvm::alignTo(getContext().getTypeSize(RetTy), 32) / 32;
if (RetSize > 4)
return getIndirectByRef(RetTy, /*HasFreeRegs*/ true);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24933: Enable configuration files in clang
ddunbar added a comment. I am too out of the loop on Clang development to be able to comment on the specific direction, but I will just say that I am highly in favor of adding new features in this direction. Thank you! https://reviews.llvm.org/D24933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [cfe-commits] r124613 - /cfe/trunk/lib/Frontend/FrontendActions.cpp
IIRC, and I can hardly guarantee I do, the issue is that libclang installing signal handlers doesn’t play well with the arbitrary applications which can be linking libclang. - Daniel On Thu, Nov 16, 2017 at 3:26 PM Rafael Avila de Espindola < rafael.espind...@gmail.com> wrote: > Daniel Dunbar writes: > > > Author: ddunbar > > Date: Mon Jan 31 16:00:44 2011 > > New Revision: 124613 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=124613&view=rev > > Log: > > libclang: Don't allow RemoveFileOnSignal to be called via libclang, > badness can > > ensue. > > > Sorry for digging out such an old commit, but do you remember what > badness that ensues if RemoveFileOnSignal is called? > > Would the same badness ensue if FILE_FLAG_DELETE_ON_CLOSE were used on > Windows? > > > Thanks, > Rafael > > > > Modified: > > cfe/trunk/lib/Frontend/FrontendActions.cpp > > > > Modified: cfe/trunk/lib/Frontend/FrontendActions.cpp > > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendActions.cpp?rev=124613&r1=124612&r2=124613&view=diff > > > == > > --- cfe/trunk/lib/Frontend/FrontendActions.cpp (original) > > +++ cfe/trunk/lib/Frontend/FrontendActions.cpp Mon Jan 31 16:00:44 2011 > > @@ -104,7 +104,10 @@ > > return true; > >} > > > > - OS = CI.createDefaultOutputFile(true, InFile); > > + // We use createOutputFile here because this is exposed via libclang, > and we > > + // must disable the RemoveFileOnSignal behavior. > > + OS = CI.createOutputFile(CI.getFrontendOpts().OutputFile, > /*Binary=*/true, > > + /*RemoveFileOnSignal=*/false, InFile); > >if (!OS) > > return true; > > > > > > > > ___ > > cfe-commits mailing list > > cfe-comm...@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D23531: [Darwin] Stop linking libclang_rt.eprintf.a
The original motivation for organizing things this way was to try and
always be in the situation where, when linking against the latest
deployment target, we should never need the extra library (because the
content will be present in libSystem). This is useful in helping to ensure
we don't unnecessarily embed copies of system provided functions.
I know it is quite cumbersome to maintain that policy, but have we
explicitly given it up? Nick, what is your opinion here?
- Daniel
On Mon, Aug 15, 2016 at 3:51 PM, Chris Bieneman wrote:
> beanz created this revision.
> beanz added reviewers: ddunbar, bob.wilson.
> beanz added a subscriber: cfe-commits.
>
> The eprintf library was added before the general OS X builtins library
> existed as a place to store one builtin function. Since we have for several
> years had an actual mandated builtin library for OS X > 10.5, we should
> just merge eprintf into the main library.
>
> This change will resolve PR28855.
>
> As a follow up I'll also patch compiler-rt to not generate the eprintf
> library anymore.
>
> https://reviews.llvm.org/D23531
>
> Files:
> lib/Driver/ToolChains.cpp
>
> Index: lib/Driver/ToolChains.cpp
> ===
> --- lib/Driver/ToolChains.cpp
> +++ lib/Driver/ToolChains.cpp
> @@ -483,8 +483,6 @@
> if (isMacosxVersionLT(10, 5)) {
>AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.10.4.a");
> } else {
> - if (getTriple().getArch() == llvm::Triple::x86)
> -AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.eprintf.a");
>AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.osx.a");
> }
>}
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r246991 - When building the alloca for a local variable, set its name
I agree with Chandler the default should be no names for -Asserts builds. What I wanted originally was that the stripping of names be a runtime choice (since the performance overhead of it was minimal when I measured it), so that when we need to debug with a production compiler, it would still be possible to get the names out. Sometimes that is invaluable when a bug only handily reproduces with a production compiler you have on hand (e.g., you might be at a users desktop) and it would help to see the names. - Daniel On Tue, Sep 8, 2015 at 11:06 AM, David Blaikie via cfe-commits < cfe-commits@lists.llvm.org> wrote: > > > On Tue, Sep 8, 2015 at 10:52 AM, Chandler Carruth > wrote: > >> None of my performance concerns were relevant to this change FWIW. >> > > Good to know - if we wanted to go down this path I figure we could just > provide overloads - StringRef and Twine, the StringRef one could always use > the name, even in -Asserts and the Twine one would not. > > But yeah, your comments below seem worth considering before we figure out > about that path. > > >> I think the reason that this got "fixed" was because people had a >> tendancy to *rely* on the name downstream when we made it always present. >> =/ Personally, I like having *no* names in a no-asserts build because it >> ensures that absolutely no one is relying on them -- we have debug >> information for that. >> >> I wonder if the right way to help the debugging scenario (which is very >> real and painful) is to expose a flag for this, or to expose a way to take >> an IR file with debug info and synthesize nice names for as much as we can >> using the debug info? >> >> On Tue, Sep 8, 2015 at 10:47 AM David Blaikie via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> On Tue, Sep 8, 2015 at 10:26 AM, John McCall wrote: >>> On Sep 8, 2015, at 8:25 AM, David Blaikie wrote: On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: rjmccall > Date: Tue Sep 8 04:18:30 2015 > New Revision: 246991 > > URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev > Log: > When building the alloca for a local variable, set its name > separately from building the instruction so that it's > preserved even in -Asserts builds. > Why do we want to preserve this name in particular in -Asserts builds? It’s a fairly small runtime cost — no twine appending, only present on a tiny fraction of instructions, unlikely to collide within a single function — that makes reading the IR dramatically easier. That’s still useful to be able to do with a production compiler, both for us and for sophisticated users. IIRC, Daniel did the perf work on IR names way back when; he might have other thoughts. >>> >>> *nod* I'd be curious to see/hear/better understand the tradeoffs. I know >>> I've talked to Chandler (CC'd) about it before when he's expressed a desire >>> to want to more fully remove names from non-asserts builds (specifically: >>> optimizations still create named values even in -Asserts builds, I think? >>> or maybe there was some other - oh, right, as you were saying, the Twine >>> building cost, even when the name isn't used some names are complex to >>> create, etc) >>> >>> John. >>> >>> ___ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >> > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D20757: Add "REQUIRES-ANY" feature test
I believe you are thinking of: http://reviews.llvm.org/D18185 On Tue, May 31, 2016 at 2:32 PM, Paul Robinson wrote: > probinson added a subscriber: probinson. > probinson added a comment. > > Do I remember that somebody was working on a more generic expression-like > syntax for REQUIRES? If that's been abandoned, then Never Mind. > > > Repository: > rL LLVM > > http://reviews.llvm.org/D20757 > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
