@@ -2282,6 +2282,15 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (MadeChange)
return &GEP;
+ // Canonicalize constant GEPs to i8 type.
brunodf-snps wrote:
Reading about the [planned
steps](https://www.npopov.c
@@ -3871,10 +3871,6 @@ def funroll_loops : Flag<["-"], "funroll-loops">,
Group,
HelpText<"Turn on loop unroller">, Visibility<[ClangOption, CC1Option]>;
def fno_unroll_loops : Flag<["-"], "fno-unroll-loops">, Group,
HelpText<"Turn off loop unroller">, Visibility<[ClangOpti
brunodf-snps wrote:
Tagging some possible reviewers: @zygoloid @AnastasiaStulova @rjmccall
https://github.com/llvm/llvm-project/pull/94346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
brunodf-snps wrote:
Another round of tagging to try to get a review: @efriedma-quic @asl
@AaronBallman can you help with reviewing or getting a reviewer? This should
really be a trivial patch, so not much work at all.
https://github.com/llvm/llvm-project/pull/94346
brunodf-snps wrote:
@efriedma-quic Thanks for the review! Could you merge this request on our
behalf? (No commit access)
https://github.com/llvm/llvm-project/pull/94346
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/brunodf-snps created
https://github.com/llvm/llvm-project/pull/94346
The `llvm.invariant.start` intrinsic is already overloaded to work with memory
objects in any address space. We simply instantiate the intrinsic with the
appropriate pointer type.
Fixes #94345.
>From ea1a
brunodf-snps wrote:
> Do we want nocapture markings on memory operands?
I had a chance to discuss this with @nikic and he brought up the LEA
instruction. The following would capture the address the `b` field:
```
asm("lea %0, %1" : "=r" (r) : "m" (p[i].b));
```
I could not find back if you ar
https://github.com/brunodf-snps created
https://github.com/llvm/llvm-project/pull/110510
This patch adds an appropriate LLVM memory effects attribute and `willreturn`
attribute to asm call instructions for extended asm statements. The existing
code of EmitAsmStmt seems to have been written bef
brunodf-snps wrote:
The intention is to enable LLVM to do more of the optimizations that GCC does
around inline asm statements.
The following example demonstrates this: https://godbolt.org/z/53rzbjW7z
All of the test cases marked as "MISSED" are also optimized by LLVM with this
patch, except f
brunodf-snps wrote:
> We need documentation for the exact assumptions we're making here.
Sure, we can try to work on this (and your other remarks). But what do you have
in mind? Since this form of inline assembly is a gcc extension, I consider the
gcc documentation and implementation authorita
brunodf-snps wrote:
I read about this commit in LLVM weekly. Thanks @fhahn and @rjmccall for adding
documentation about strict aliasing! This is always a difficult topic for our
users.
One remark though. The documentation states:
> `void*` is permitted to alias any pointer type, `void**` is pe
brunodf-snps wrote:
> We're documenting a weaker guarantee than we implement, yes.
OK, thanks. I guess the wording "in Clang 20, [...] Clang now distinguishes
different pointers by their pointee type, except as limited by the relaxations
around qualifiers and `void*` described above" led me to
brunodf-snps wrote:
> I think we can continue to refine our implementation, yeah. [...] The
> supertype-ish reasoning I laid out above seems like the right idea.
Thanks. FWIW, I think this can be implemented as laid out in #126047.
https://github.com/llvm/llvm-project/pull/122116
_
https://github.com/brunodf-snps created
https://github.com/llvm/llvm-project/pull/126047
Commit 77d3f8a avoids distinct tags for any pointers where the ultimate pointee
type is `void`, to solve breakage in real-world code that uses (indirections
to) `void*` for polymorphism over different poin
@@ -256,7 +277,7 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
// similar-types rule.
const auto *RT = Ty->getAs();
if (!RT)
-return AnyPtr;
+return getAnyPtr();
brunodf-snps wrote:
Yes, I agree this shoul
https://github.com/brunodf-snps updated
https://github.com/llvm/llvm-project/pull/126047
>From f516639a2bfe5cad76ac82684877f46ac6260077 Mon Sep 17 00:00:00 2001
From: Bruno De Fraine
Date: Thu, 6 Feb 2025 11:50:44 +0100
Subject: [PATCH 1/3] [TBAA] Refine pointer-tbaa for void pointers by pointe
brunodf-snps wrote:
> I'm not qualified to review this, so please make sure you understand changes
> to CWG158 test and they are what you expect. Specifically, I'd like to avoid
> updating the test just to make FileCheck happy.
All the updates to FileCheck patterns match what I expected. The a
https://github.com/brunodf-snps updated
https://github.com/llvm/llvm-project/pull/126047
>From f516639a2bfe5cad76ac82684877f46ac6260077 Mon Sep 17 00:00:00 2001
From: Bruno De Fraine
Date: Thu, 6 Feb 2025 11:50:44 +0100
Subject: [PATCH 1/4] [TBAA] Refine pointer-tbaa for void pointers by pointe
@@ -80,6 +80,28 @@ llvm::MDNode *CodeGenTBAA::getChar() {
return Char;
}
+llvm::MDNode *CodeGenTBAA::getAnyPtr(unsigned PtrDepth) {
+ assert(PtrDepth >= 1 && "Pointer must have some depth");
+
+ // Populate at least PtrDepth elements in AnyPtrs. These are the type nodes
+
brunodf-snps wrote:
@Endilll @rjmccall OK to merge.
https://github.com/llvm/llvm-project/pull/126047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
brunodf-snps wrote:
If no other remarks get raised, I think this can be merged in a day or two?
(Will have to be done by someone with commit access.)
https://github.com/llvm/llvm-project/pull/126047
___
cfe-commits mailing list
cfe-commits@lists.llvm.
21 matches
Mail list logo
