https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/109056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3442,6 +3442,35 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
rj
@@ -3442,6 +3442,13 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
+if (auto *MPT
@@ -3442,6 +3442,13 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
rj
rjmccall wrote:
Okay, so if the ultimate pointee type is `void`, we're basically treating that
as a generic pointer, no matter what the pointer depth is? I guess that makes
sense.
> What would be a good place to document this?
Hmm, I was hoping that we would have a section in the manual alre
rjmccall wrote:
I agree that allowing `void*` l-values to alias arbitrary pointer objects is
probably the right pragmatic choice. We should document it, though.
@pinskia, does GCC apply this recursively — e.g. are `void**` l-values treated
specially in any way, or are they basically just `char
@@ -0,0 +1,37 @@
+// RUN: split-file %s %t
+// RUN: python %t/gen.py %t/switch-overflow.c %t/tmp.c && %clang_cc1
-emit-llvm %t/tmp.c -o - | FileCheck %t/tmp.c
+
+//--- gen.py
rjmccall wrote:
If you don't mind working on the representation issue, I think that wou
rjmccall wrote:
> FYI it looks like this has a fairly large impact on compile-time, esp at `O0`
> with a clang host compiler
> (https://llvm-compile-time-tracker.com/compare.php?from=1fcb6a9754a8db057e18f629cb90011b638901e7&to=4797437463e63ee289a1ff1904cfb7b2fe6cb4c2&stat=instructions%3Au).
>
rjmccall wrote:
> > > Let's just increase to 9 bits.
> > > Have you checked whether the size of `Stmt` or `Expr` changes when you do
> > > this?
> >
> >
> > @rjmccall I've changed it to 9 bits and checked that `Stmt` and `Expr` are
> > still 8 bytes and 16 bytes resp..
>
> I think checking j
https://github.com/rjmccall commented:
Let's just increase to 9 bits.
Have you checked whether the size of `Stmt` or `Expr` changes when you do this?
https://github.com/llvm/llvm-project/pull/120341
___
cfe-commits mailing list
cfe-commits@lists.llvm.
@@ -225,7 +225,9 @@ ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
bool Variadic,
// Records with non-trivial destructors/copy-constructors should not be
// passed by value.
if (auto RAA = getRecordArgABI(Ty, getCXXABI()))
- return getNaturalAlign
@@ -800,7 +800,9 @@ static ABIArgInfo classifyExpandedType(SwiftAggLowering
&lowering,
if (lowering.empty()) {
return ABIArgInfo::getIgnore();
} else if (lowering.shouldPassIndirectly(forReturn)) {
-return ABIArgInfo::getIndirect(alignmentForIndirect, /*byval*/ fal
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/114062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -225,7 +225,9 @@ ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
bool Variadic,
// Records with non-trivial destructors/copy-constructors should not be
// passed by value.
if (auto RAA = getRecordArgABI(Ty, getCXXABI()))
- return getNaturalAlign
https://github.com/rjmccall requested changes to this pull request.
I'm fine with how you're handling the address spaces for now.
I'd like to talk about the rule you're implementing, though. It looks like
it's supposed to be:
- return values always use the alloca AS
- arguments always use the
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/114062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -800,7 +800,9 @@ static ABIArgInfo classifyExpandedType(SwiftAggLowering
&lowering,
if (lowering.empty()) {
return ABIArgInfo::getIgnore();
} else if (lowering.shouldPassIndirectly(forReturn)) {
-return ABIArgInfo::getIndirect(alignmentForIndirect, /*byval*/ fal
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/114062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
Yes, I believe that's essentially just a version of the rewriter that uses a
different ABI (it tries to match the non-fragile Apple ObjC runtime rather than
the fragile one).
https://github.com/llvm/llvm-project/pull/119269
___
cfe-co
rjmccall wrote:
`test/Rewrite` is for the Objective-C => MSVC-compatible C++ rewriter
(`-rewrite-objc`), which is a different feature. That feature might *also* be
obsolete, but we haven't signed off on that yet AFAIK.
https://github.com/llvm/llvm-project/pull/119269
_
rjmccall wrote:
Apple actually removed this migrator from Xcode 16. As far as Apple is
concerned, this is now dead code, and we intend to open a PR to remove it (but
thank you for the prompt!).
https://github.com/llvm/llvm-project/pull/116792
___
cfe
@@ -1085,8 +1085,10 @@ llvm::Value *CodeGenFunction::EmitBlockLiteral(const
CGBlockInfo &blockInfo) {
blockAddr.getPointer(),
ConvertType(blockInfo.getBlockExpr()->getType()));
if (IsOpenCL) {
-CGM.getOpenCLRuntime().recordBlockInfo(blockInfo.BlockExpression, Inv
@@ -1780,6 +1786,15 @@ void CXXNameMangler::mangleDeviceStubName(const
IdentifierInfo *II) {
<< II->getName();
}
+void CXXNameMangler::mangleOCLDeviceStubName(const IdentifierInfo *II) {
+ // ::= __clang_ocl_kern_imp_
+ // ::= [n]
+ // ::=
+ StringRef OCLDevi
@@ -1780,6 +1786,15 @@ void CXXNameMangler::mangleDeviceStubName(const
IdentifierInfo *II) {
<< II->getName();
}
+void CXXNameMangler::mangleOCLDeviceStubName(const IdentifierInfo *II) {
+ // ::= __clang_ocl_kern_imp_
+ // ::= [n]
+ // ::=
+ StringRef OCLDevi
@@ -71,14 +71,19 @@ class GlobalDecl {
GlobalDecl(const FunctionDecl *D, unsigned MVIndex = 0)
: MultiVersionIndex(MVIndex) {
if (!D->hasAttr()) {
+ if (D->hasAttr()) {
+Value.setPointerAndInt(D, unsigned(KernelReferenceKind::Kernel));
+return;
@@ -1085,8 +1085,10 @@ llvm::Value *CodeGenFunction::EmitBlockLiteral(const
CGBlockInfo &blockInfo) {
blockAddr.getPointer(),
ConvertType(blockInfo.getBlockExpr()->getType()));
if (IsOpenCL) {
-CGM.getOpenCLRuntime().recordBlockInfo(blockInfo.BlockExpression, Inv
https://github.com/rjmccall requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/115821
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2343,6 +2343,15 @@ void CodeGenModule::ConstructAttributeList(StringRef
Name,
// Collect function IR attributes from the CC lowering.
// We'll collect the paramete and result attributes later.
CallingConv = FI.getEffectiveCallingConvention();
+ GlobalDecl GD = Calle
@@ -5692,7 +5692,10 @@ CGCallee CodeGenFunction::EmitCallee(const Expr *E) {
// Resolve direct calls.
} else if (auto DRE = dyn_cast(E)) {
if (auto FD = dyn_cast(DRE->getDecl())) {
- return EmitDirectCallee(*this, FD);
+ auto CalleeDecl = FD->hasAttr()
+
rjmccall wrote:
I haven't looked at your patch yet, and I'm not familiar with the `diagnose_if`
feature; I'm just commenting about the AST design question because I was tagged
in to do so. If `diagnose_if` is about compile-time evaluation — essentially
assertion failures during constant evalua
rjmccall wrote:
> An abstraction that includes blocks doesn't help us here because we are
> looking for the combination of `NamedDecl` and `DeclContext` and `BlockDecl`
> isn't a `NamedDecl`.
I think you're focusing a little narrowly here. I can't imagine why you'd
specifically need a `NamedD
https://github.com/rjmccall commented:
This seems reasonable to me. Since it's standards-compliant, has a specific
opt-out flag, and is overridden by the general `-fno-strict-aliasing` flag, I
don't see any need for the RFC process. Still, you should definitely wait for
more feedback, especial
rjmccall wrote:
Having an abstraction for this would be nice. It doesn't *have* to be a base
class specifically, though; we can do a more extrinsic tagged-union without
actually unifying the class hierarchies, like `llvm::CallSite` does. Swift has
a type called `AnyFunctionRef` that unifies se
https://github.com/rjmccall approved this pull request.
https://github.com/llvm/llvm-project/pull/116596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/116596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -249,6 +249,21 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!Ty->isRecordType())
return AnyPtr;
+ // For unnamed structs or unions C's compatible types rule applies. Two
+ // compatible types in different compilation units c
https://github.com/rjmccall approved this pull request.
https://github.com/llvm/llvm-project/pull/116991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -205,14 +205,27 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
llvm::MDNode *AnyPtr = createScalarTypeNode("any pointer", getChar(),
Size);
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
-// Compute the depth of the pointer and generate a
@@ -18,10 +20,23 @@ struct A {};
// CHECK-LABEL: define {{.*}} @_Z1g
const int *(A::*const *g(const int *(A::* const **p)[3], int
*(A::***q)[3]))[3] {
+ // CHECK: load ptr, ptr %p.addr
// CHECK: load ptr, {{.*}}, !tbaa ![[MEMPTR_TBAA:[^,]*]]
const int *(A::*const *x)[3
@@ -230,6 +243,12 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // Be conservative if the type isn't a RecordType. We are specifically
rjmccall wrote:
```suggestion
https://github.com/rjmccall requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/116991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
@@ -230,6 +232,11 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // Be conservative if the type a MemberPointerType. Those would require
+ // stripping const-qualifiers inside the typ
rjmccall wrote:
Hmm. We're talking here about C++'s type similarity rules, which come from C++
[conv.qual]p1:
> A cv-decomposition of a type T is a sequence of cv_i and P_i such that T is
> “cv_0 P_0 cv_1 P_1 ··· cv_n−1 P_n−1 cv_n U” for n ≥ 0, where each cv_i is a
> set of cv-qualifiers, an
rjmccall wrote:
Yeah, that's my take as well. Anything we do to make this work better risks
being interpreted as treating this as somehow supported, which it absolutely is
not.
https://github.com/llvm/llvm-project/pull/116881
___
cfe-commits mailing
@@ -230,6 +230,15 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // For unnamed structs or unions C's compatible types rule applies. Two
+ // compatible types in different compilation
rjmccall wrote:
I'm sorry if you've explained this before, but I thought our general approach
was to just store the options in individual expressions, and CodeGen should in
general already be paying attention to those options. Is there a specific
reason we also need to honor these at the comp
rjmccall wrote:
The ABI spec is pretty clear about this, and demangling is likely to get very
screwed up because of the inconsistency.
I think should do the following:
- We should file a bug with GCC pointing out the problem.
- We should fix the bug under new `-fclang-abi-compat=` versions, bu
@@ -5159,16 +5156,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
} else if (!ReturnValue.isNull()) {
SRetPtr = ReturnValue.getAddress();
} else {
- SRetPtr = CreateMemTemp(RetTy, "tmp", &SRetAlloca);
+ SRetPtr = CreateMemTempWith
@@ -5390,11 +5390,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
V->getType()->isIntegerTy())
V = Builder.CreateZExt(V, ArgInfo.getCoerceToType());
-// If the argument doesn't match, perform a bitcast to coerce it. This
-
@@ -5390,11 +5390,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
V->getType()->isIntegerTy())
V = Builder.CreateZExt(V, ArgInfo.getCoerceToType());
-// If the argument doesn't match, perform a bitcast to coerce it. This
-
https://github.com/rjmccall approved this pull request.
Code LGTM. I would still prefer this PR to just contain the NFC refactor, with
a follow up that adds the semantic changes to the AMDGPU and NVPTX targets.
https://github.com/llvm/llvm-project/pull/115777
___
@@ -697,45 +699,21 @@ class Qualifiers {
/// every address space is a superset of itself.
/// CL2.0 adds:
/// __generic is a superset of any address space except for __constant.
- static bool isAddressSpaceSupersetOf(LangAS A, LangAS B) {
-// Address spaces must
@@ -697,45 +699,21 @@ class Qualifiers {
/// every address space is a superset of itself.
/// CL2.0 adds:
/// __generic is a superset of any address space except for __constant.
- static bool isAddressSpaceSupersetOf(LangAS A, LangAS B) {
-// Address spaces must
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -17,34 +17,34 @@
#include "clang/Basic/TargetInfo.h"
#include "clang/Basic/TargetOptions.h"
#include "llvm/Support/Compiler.h"
+#include "llvm/Support/NVPTXAddrSpace.h"
#include "llvm/TargetParser/Triple.h"
#include
namespace clang {
namespace targets {
static cons
@@ -31,6 +31,7 @@ namespace clang {
template class CanProxy;
template struct CanProxyAdaptor;
class CXXRecordDecl;
+class ASTContext;
rjmccall wrote:
Minor nit: these are alphabetized.
https://github.com/llvm/llvm-project/pull/115777
_
https://github.com/rjmccall commented:
Broadly LGTM. A few structural requests.
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
Oh, you can just forward-declare `class ASTContext` at the top of that file.
It's funny that that isn't already there.
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
rjmccall wrote:
I'm not sure what you're saying would need to pulled into a .cpp file. It
looks like there's only one actual call to `TI.isAddressSpaceSupersetOf`, so if
you just pass around an `ASTContext &` to that point, nothing else will need to
drill into it. And frankly that entire exp
rjmccall wrote:
> Okay the problem with using `ASTContext` here is that it creates some
> recursive includes. ~I can do this by moving the check into `Type.cpp`
> instead, so this will be function call instead of being inlined.~ This would
> require a lot of extra stuff so I'm going to defer i
rjmccall wrote:
Address spaces from language dialects generally have required relationships and
behaviors in the language, and that really shouldn't be overridden by targets.
However, targets do need to be able to decide how target-specific address
spaces work, including how they interact with
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/116100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1780,6 +1780,14 @@ class TargetInfo : public TransferrableTargetInfo,
return 0;
}
+ /// \returns Target specific address space for indirect (e.g. sret)
arguments.
+ /// If such an address space exists, it must be convertible to and from the
+ /// alloca address s
rjmccall wrote:
I don't think there's any situation in which Clang needs to change the address
space of a declaration. It can happen if the programmer has declarations that
disagree about the address space in which the entity is defined, but it's fair
to just emit an error in that situation.
rjmccall wrote:
> > Can we find a way to re-use the code between this and the actual lookup
> > code? Feels like we could have some sort of predicate like
> > `doesLookupResultSuppressADL(NamedDecl*)`. Or are we forced to use slightly
> > different predicates for some compatibility reason?
>
@@ -1672,10 +1672,11 @@ CodeGenTypes::GetFunctionType(const CGFunctionInfo &FI)
{
// Add type for sret argument.
if (IRFunctionArgs.hasSRetArg()) {
-QualType Ret = FI.getReturnType();
-unsigned AddressSpace = CGM.getTypes().getTargetAddressSpace(Ret);
+auto Ad
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/108970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/113691
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
I agree that it doesn't meaningfully come from a source-level type and should
be specified by the target lowering. I just want to make sure we write the new
code in a way that plausibly supports the target ABI specifying something other
than "it's always in the alloca AS". Ca
rjmccall wrote:
Is this a target-independent decision? I could certainly imagine a target with
a generic AS wanting to specify that indirect return addresses (and maybe even
parameters?) should be in that rather than the alloca AS; among other things,
it would allow return values to be used t
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/110569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -119,6 +120,7 @@ class CodeGenTBAA {
llvm::Module &Module;
const CodeGenOptions &CodeGenOpts;
const LangOptions &Features;
+ MangleContext *MangleCtx;
rjmccall wrote:
This should either be a unique_ptr or you need to delete it in the destructor.
htt
https://github.com/rjmccall commented:
Thanks, LGTM other than the memory leak.
https://github.com/llvm/llvm-project/pull/110569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/110569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -221,21 +221,27 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
PtrDepth++;
Ty = Ty->getPointeeType().getTypePtr();
} while (Ty->isPointerType());
-// TODO: Implement C++'s type "similarity" and consider dis-"similar"
-// pointers d
@@ -221,21 +221,27 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
PtrDepth++;
Ty = Ty->getPointeeType().getTypePtr();
} while (Ty->isPointerType());
-// TODO: Implement C++'s type "similarity" and consider dis-"similar"
-// pointers d
https://github.com/rjmccall requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/110569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -221,21 +221,27 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
PtrDepth++;
Ty = Ty->getPointeeType().getTypePtr();
} while (Ty->isPointerType());
-// TODO: Implement C++'s type "similarity" and consider dis-"similar"
-// pointers d
https://github.com/rjmccall approved this pull request.
https://github.com/llvm/llvm-project/pull/112218
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
Nice, this looks really clean. Thanks for taking this on!
https://github.com/llvm/llvm-project/pull/110762
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
https://github.com/rjmccall approved this pull request.
Thanks, that looks good.
https://github.com/llvm/llvm-project/pull/111597
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/111597
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -75,6 +75,12 @@ const CGFunctionInfo &arrangeCXXMethodType(CodeGenModule
&CGM,
const FunctionProtoType *FTP,
const CXXMethodDecl *MD);
+const CGFunctionInfo &arrangeCXXMethodCall(CodeGenM
rjmccall wrote:
Oh, that's interesting. I'd been assuming this was a cross-function issue or
something like that, but that's a great example of where we need more than
that. I agree that it feels like having some kind of barrier instruction is
the right way to go — basically a unary operator
rjmccall wrote:
I don't understand what fast-math flags are supposed to mean for loads, phis,
and selects. These are not arithmetic operations; they just propagate values.
If you're trying to implement some kind of rule where fast-math analysis should
not pass across certain kinds of abstrac
rjmccall wrote:
Are you suggesting that loads need to have fast-math flags attached to them?
Because this sounds like a bad representation in IR.
https://github.com/llvm/llvm-project/pull/105912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rjmccall wrote:
Yeah, the conditional operator doesn't do any floating-path math itself. If
the first operand is a floating-point expression, we should always be modeling
that with a float-to-boolean conversion, and the flags should go there.
https://github.com/llvm/llvm-project/pull/105912
_
rjmccall wrote:
I don't think there's a deep reason blocks and lambdas don't use quite the same
scope mechanics in the compiler, so if you wanted to pursue that, it seems
reasonable. But this approach also seems viable. I agree that removing the
assertion would be the wrong thing to do, and
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/109056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 968 matches
Mail list logo
