Displaying 10 results from an estimated 10 matches for "elyont0wepii6unfk".
2019 Jun 05
2
llvm-ir: TBAA and struct copies
...VRomY-
> z_Vgfx6dv1OKq85hoK5rRXP8m6Rxs&s=TmYSKjBxhgw5sSVeq-
> v7p1UmvzV_81OIMz-_pFakoZQ&e=
> > [2] godbolt example with single struct:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.godbolt.org_z_XcQy-
> 2DU&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-
> OSzxlGOXXSfAvOLT6E8iPwwJk&m=b7XmqIDwVRomY-
> z_Vgfx6dv1OKq85hoK5rRXP8m6Rxs&s=4OL_Z9OECS7bHERaUU-
> WMxWhDPt-f_17zpehoMGVgj4&e=
> > [3] godbolt example with nested struct:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.godbolt.org_z_mNd-
> 2DiI&a...
2020 Feb 20
2
Given one restrict pointer based on another, should they never alias?
...x and y be in the
> same restrictness "bucket" since y is based on x?
>
> [1] http://port70.net/~nsz/c/c11/n1570.html#6.7.3.1
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__port70.net_-7Ensz_c_c11_n1570.html-236.7.3.1&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-OSzxlGOXXSfAvOLT6E8iPwwJk&m=xMDqkSAlj-YCOS4JMDXAENpBS-eaCcLYSkIm1qK68fs&s=B3LRzqpd9bD1724nvhG0FtpFh3QPsQ4FTBGQ4qJn1cA&e=>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200219/14510c24/at...
2019 Jun 04
2
llvm-ir: TBAA and struct copies
Hi,
I have a question about the current definition of TBAA (See [1]).
In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue)
For following c-alike code:
struct S { int dummy; short e, f; } x,y;
struct S* p = &x;
int foobar() {
x.f=42;
*p=y; //**** struct copy
return x.f;
}
We produce:
2020 Jan 22
4
Inlining + CSE + restrict pointers == funtimes
So I've been narrowing down a very fun issue in our Burst compiler stack
with respect to noalias support, and I've managed to basically boil this
down to the following failure (see https://godbolt.org/z/-mdjPV):
int called(int* __restrict__ a, int* b, int* c) {
return *a + *b + *c;
}
int foo(int * x, int * y) {
return *x + *y + called(x, x, y);
}
int bar(int * x, int * y) {
return
2020 Feb 14
2
Given one restrict pointer based on another, should they never alias?
We recently found an issue when using the full restrict implementation
developed by Jeroen; it surfaces when compiling an obscure combination of
std::valarray and std::indirect_array but I don't want to bore you with all
the details. What it boils down to is this basic question about restrict:
Given one restrict pointer based on another, should they never alias?
As far as I understand the
2020 Jan 22
2
Inlining + CSE + restrict pointers == funtimes
...sue in our Burst compiler stack with respect to noalias support, and I've managed to basically boil this down to the following failure (see https://godbolt.org/z/-mdjPV<https://urldefense.proofpoint.com/v2/url?u=https-3A__godbolt.org_z_-2DmdjPV&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-OSzxlGOXXSfAvOLT6E8iPwwJk&m=aOzDT5OLTyJR4khihblFI8hsLwAXqccKhWgUehiRiR4&s=XWkvlt9v4v-iBS_HFjm8-b3FQVTO3UCsgWPECbAPkX4&e=>):
int called(int* __restrict__ a, int* b, int* c) {
return *a + *b + *c;
}
int foo(int * x, int * y) {
return *x + *y + called(x, x, y);
}
int bar(int * x, int...
2018 Aug 17
2
local restrict - again
On 06/28/2018 10:59 AM, Hal Finkel wrote:
> Hi, Jeroen,
>
> We should move these conversations to llvm-dev so that they don't get
> missed and others can contribute. Can I cc the list?
[+llvm-dev] - Jeroen consented.
>
> Doing this will mean that the logic for when to remove dead llvm.noalias
> intrinsics will become more complicated. That might be worthwhile. So
>
2020 Jan 17
3
Help with SROA throwing away no-alias information
I'm having an issue where SROA will throw away no-alias information on some
loads after inlining, because the loads are derived from a store to an
alloca which can be removed after inlining.
The pointers that were originally stored into the alloca do *not *have any
aliasing information - the only context that allowed me to assert aliasing
was that the inlined-function guaranteed it to be so.
2020 Feb 05
3
IndVarSimplify: getBackedgeTakenCount and Release vs Assert
Hi,
I am investigating a difference in code generation between release and assert builds of llvm.
The culprit is IndVarSimplify that comes up with different behavior on the same input:
in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition'
After digging around, it seems that following change is the culprit:
-----
Author: Philip Reames <listmail at
2017 Aug 23
3
Extending TableGen's 'foreach' to work with 'multiclass' and 'defm'
On 08/23/2017 12:44 PM, David Chisnall wrote:
> On 23 Aug 2017, at 18:21, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> On 08/23/2017 12:06 PM, Krzysztof Parzyszek via llvm-dev wrote:
>>> On 8/23/2017 11:58 AM, Hal Finkel via llvm-dev wrote:
>>>> If we want to go down that route, I can certainly imagine a feasible