Displaying 20 results from an estimated 1100 matches similar to: "llvm is getting slower, January edition"
2017 Jan 18
2
llvm is getting slower, January edition
On 1/18/17 3:55 PM, Davide Italiano via llvm-dev wrote:
> On Tue, Jan 17, 2017 at 6:02 PM, Mikhail Zolotukhin
> <mzolotukhin at apple.com> wrote:
>> Hi,
>>
>> Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100%
2017 Jan 20
2
llvm is getting slower, January edition
Ah but how did you compile the clang-4.0 you were using? Does it run faster
if you compile it with clang-4.0? :)
On Fri, Jan 20, 2017 at 4:09 AM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> On this topic, I just tried to build ToT with clang-3.9.1 and clang-4.0
> and the total time to complete `ninja clang` on this machine went from
> 12m54s to
2015 Dec 11
2
RFC: New function attribute HasInaccessibleState
<<<
I may misunderstand, but it seems to me that this solves only query for aliasing with a pointer known to be pointing only to globals defined in the current compilation unit.
For any pointer which "may point somewhere else”, you won’t be able to resolve the non-aliasing with the “internal state” for malloc/free, right?
To take the original example in this thread:
int *x =
2015 Dec 11
2
RFC: New function attribute HasInaccessibleState
----- Original Message -----
> From: "Mehdi Amini" <mehdi.amini at apple.com>
> To: "Joseph Tremoulet" <jotrem at microsoft.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, December 11, 2015 1:28:05 PM
> Subject: Re: [llvm-dev] RFC: New function attribute
2015 Dec 11
3
RFC: New function attribute HasInaccessibleState
----- Original Message -----
> From: "Joseph Tremoulet" <jotrem at microsoft.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, December 11, 2015 3:35:38 PM
> Subject: RE: [llvm-dev] RFC: New function attribute
2015 Dec 04
2
RFC: New function attribute HasInaccessibleState
Hi,
This email is in continuation to the mail thread
http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html, to
propose a new function attribute that can convey that a function maintains
state, but this state is inaccessible to the rest of the program under
compilation.
Such a flag could be added to most libc/system calls such as
printf/malloc/free. (libc and system calls do
2015 Dec 04
4
RFC: New function attribute HasInaccessibleState
>is this "internal state” supposed to be private to the function?
It could be private or not. Hence the name "inaccessible", to mean that the
program under compilation has no access to the state. So while printf and
malloc (for example) could share state in libc, the program under
compilation cannot access this state.
>how this flag would prevent the last “optimization”
2015 Dec 14
3
RFC: New function attribute HasInaccessibleState
----- Original Message -----
> From: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Joseph Tremoulet" <jotrem at microsoft.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>
> Sent: Sunday, December 13, 2015 9:50:25 PM
> Subject: Re: [llvm-dev] RFC: New function attribute
2015 Dec 14
2
RFC: New function attribute HasInaccessibleState
Hi,
If these are the options, I'm also in favour of approach B. Approach A
redefines ReadNone, which I don't think is acceptable.
James
On Mon, 14 Dec 2015 at 08:15 Vaivaswatha Nagaraj via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> >I am in favor of approach B (although perhaps with different names).
> Just to clarify, this does not requires any propagation of
2015 Dec 04
2
RFC: New function attribute HasInaccessibleState
>but is there or is there not accessible, visible state,
Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means
it doesn't access any of the visible (accessible) states.
- Vaivaswatha
On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> Hi,
>
> I don't think the attribute as is is strong enough to do what you
2015 Dec 14
2
RFC: New function attribute HasInaccessibleState
Vaivaswatha Nagaraj via llvm-dev wrote:
> >I'm against adding this as a "subtractive" attribute. We need to add these as new attributes, not as an attribute that
> makes readonly a little less read only. I believe we're in agreement on this point.
> Just to make sure I understood right, below are the things that need to be done:
> (Approach A)
> 1. We
2015 Dec 04
2
RFC: New function attribute HasInaccessibleState
>what is a non-public state that no-one but you can access? (I’d call that
private).
malloc and free could both use global variables that are defined in libc,
but are inaccessible to the program under compilation.
>if you’re attribute is saying they have some internal state, then malloc()
cannot access the state of free() and vice versa.
Which is why it would be preferable to call it
2015 Dec 04
2
RFC: New function attribute HasInaccessibleState
>there would be two disjoint global states
In some sense yes, but technically not disjoint. Functions marked with this
attribute should still be able to access the globals within the program
under compilation, if its not marked with ReadNone.
>If malloc and free can both use global variables (there is no notion of
library in the compiler)
Inaccessible state here refers to any global that is
2020 Jul 26
2
[LAA] RtCheck on pointers of different address spaces.
Hi Stefanos,
Attached the testcase. I tried to reduce it further, but the problem goes away when I remove the instructions further.
There is a nested loop and the fault occurs while processing the inner loop (for.body)
To reproduce the crash:
opt -O3 testcase.ll -o out.ll
> `groupChecks()` will only try to group pointers that are on the same alias set.
If that’s true, the RT check
2015 Dec 09
5
RFC: New function attribute HasInaccessibleState
Sigh... let me try that last part again:
Maybe GlobalsAA and/or a GlobalsAA-centric attribution pass could partition writes as:
1. Stores to local allocas
2. Stores through pointer parameters
3. Stores to globals defined in this compilation unit
4. Other
Attributing functions with attributes:
readonly: only writes of type 1
argmemonly: only writes of type 1/2
almost-readonly: only
2015 Dec 04
4
RFC: New function attribute HasInaccessibleState
>What if you had bitcode versions of your C library
Then the definitions for these functions would be available. Would we still
set function attributes to these functions in FunctionAttrs.cpp if their
definitions were available?
>This also seems a bit tailored to malloc/free, and can't work for
user-defined allocation functions
I don't think so. For example, printf would have the
2020 Jul 26
2
[LAA] RtCheck on pointers of different address spaces.
Hello,
I Have a question related to the RT check on pointers during Loop Access Analysis pass.
There is a testcase with loop code that consist of 4 different memory operations referring two global objects of different address spaces.
One from global constant (address space 4, addr_size = 64) and the other from local, LDS (address space 3, addr_size= 32).
(Details of various address spaces
2015 Dec 03
3
Function attributes for LibFunc and its impact on GlobalsAA
----- Original Message -----
> From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 3, 2015 4:41:46 AM
> Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA
>
>
2015 Dec 03
3
GlobalsAA from GVN
Hi James,
Thanks for the help. From the log, I could infer that SLP vectorizer is not
preserving alias analysis, preventing GVN from getting the info. Although
the first function to get compiled has GlobalsAA available during GVN, rest
of them do not as SLP vectorizer run on that function invalidates GlobalsAA
which is a module pass. Is there a way to force re-computation of a
particular
2015 Dec 02
2
GlobalsAA from GVN
Hi,
I've noticed that alias analysis queries arising from GVN do not use the
results from GlobalsAA.
The last call to AAResultsWrapperPass::runOnFunction() before GVN does not
add GlobalsAAWrapperPass due to unavailability. This leads to the alias
queries from GVN not having any globals mod-ref info.
Is this a known issue? and is there any way to have globals mod-ref info
available for GVN?