similar to: [LLVMdev] 64-bit Attributes?

On Thu, Jan 12, 2012 at 2:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi, > > Is anyone working on this? If not, I can have a look -- it would be nice > to have a no_split_stacks attribute too. > I'm pretty sure Kostya is working on it... -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Jan 12, 2012 at 3:13 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Thu, Jan 12, 2012 at 2:07 AM, Sanjoy Das < > sanjoy at playingwithpointers.com> wrote: > >> Hi, >> >> Is anyone working on this? If not, I can have a look -- it would be nice >> to have a no_split_stacks attribute too. >> > > I'm pretty sure Kostya is

The change is not just to replace "typedef unsigned Attributes" with "typedef uint64_t Attributes". The problem is that 'unsigned' is used instead of 'Attributes' all over the place. How about implementing Attributes as a class with 64-bit integer under the hood? This will protect us from erroneous casts to/from 32-bit unsigned. I have a change half-done but I

On Tue, Apr 11, 2017 at 3:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Kostya, > > On April 11, 2017 at 2:39:44 PM, Kostya Serebryany (kcc at google.com) wrote: > > > ptr0 = malloc(); > > > free(ptr0); > > > ptr1 = malloc(); > > > > > > ptr0 and ptr1 will be NoAlias despite overlapping (there is actually a > >

My change 225282 broke an asan test [1], but by the time I got around to trying to revert it, I noticed that the test had started passing. Moreover, it seems to have been "fixed" by 225291 which at least does not seem related to the breakage directly. I'm puzzled now -- is the failing asan test flaky? Should I still revert 225282? Thank you for your time! [1]:

Hi Kostya, > How about implementing Attributes as a class with 64-bit integer under the > hood? > This will protect us from erroneous casts to/from 32-bit unsigned. > I have a change half-done but I want to know llvmdev's opinion before > proceeding. Yes, this sounds like a proper approach. Which will allow us to switch over other implementation of attributes, if necessary. --

On Tue, Apr 11, 2017 at 1:40 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi, > > On April 11, 2017 at 1:37:20 PM, Sanjoy Das > (sanjoy at playingwithpointers.com) wrote: > > Hi Kostya, > > > > On April 11, 2017 at 1:30:10 PM, Kostya Serebryany (kcc at google.com) > wrote: > > > > > of course, but accesses are done via pointers,

Hi! Attached my pre-midterm GSoC work for segmented stacks for review (with the required fixes). Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-command-line-option-to-enable-segmented-stacks.patch Type: text/x-diff Size: 1699 bytes Desc: not available URL:

On Jan 12, 2012, at 1:03 PM, Anton Korobeynikov wrote: > Hi Kostya, > >> How about implementing Attributes as a class with 64-bit integer under the >> hood? >> This will protect us from erroneous casts to/from 32-bit unsigned. >> I have a change half-done but I want to know llvmdev's opinion before >> proceeding. > Yes, this sounds like a proper

Apologies: didn't notice how old this thread is before replying. On Tue, Mar 22, 2016 at 5:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Vivek, > > [+CC Matthias, Quentin] > > Inter-procedural register allocation can be a big win, but my estimate > is that it will be challenging to complete within one summer unless > you're already familiar

No need to apologize this thread surely deserved some answers :) From my perspective this project sounds doable. I would expect the register allocation parts to be not too hard: I imagine this being just distilling a new clobber regmask after allocating a function. I would expect the challenging (or annoying) part to get a machine module pass (or a similar mechanism to influence the order in

The pass manager already has support for calligraph connected region IIRC. As for the regmask part, we probably could hack something up in a week or so, but I believe this is not what Vivek had in mind. I think the main challenge of a real inter-procedural register allocator is to change all of the calling convention dynamically and more importantly convey the right information to other tools

On 08/10/2011 11:03 AM, Sanjoy Das wrote: > Hi! > > Attached my pre-midterm GSoC work for segmented stacks for review (with > the required fixes). Nice work! + extern bool EnableSegmentedStacks; Can you add a comment like the other declarations? I think the patch looks good. There are possible improvements, but the patch is already in an state where it can be tested and extended

> On Mar 22, 2016, at 6:04 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > No need to apologize this thread surely deserved some answers :) > > From my perspective this project sounds doable. I would expect the register allocation parts to be not too hard: I imagine this being just distilling a new clobber regmask after allocating a function. I would

> On Jun 11, 2015, at 12:48 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > On Thu, Jun 11, 2015 at 12:02 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >> >>> On Jun 10, 2015, at 11:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >>> >>>> Base is treated as unsigned so

> On Mar 23, 2016, at 2:44 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > > Vivek Pandya > > > On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > The pass manager already has support for calligraph connected region IIRC. > If I am not wrong Quentin and Mehdi Amini

*Vivek Pandya* On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at apple.com> wrote: > The pass manager already has support for calligraph connected region IIRC. > If I am not wrong Quentin and Mehdi Amini refers to CallGraphSCCPass.cpp > As for the regmask part, we probably could hack something up in a week or > so, but I believe this is not what Vivek had in

Hi Sanjoy, Reading through LoopDependenceAnalysis::analyseStrongSIV(), I noticed one problem and one confusion. My confusion related to your naming of the two instructions as A and B. It's consistent all through LoopDependenceAnalysis. I'd prefer something like source and destination, so I can keep track of which is which. It didn't matter so much when you were simply proving or

On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Couple of other examples: > > void @foo(i32* %ptr) available_externally { > %discard = load i32, i32* %ptr > } > void bar() { > call @foo(i32* %x) > } > > ==> > > void @foo(i32* %ptr) available_externally { > } > void bar() { >

> On Mar 23, 2016, at 2:59 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 23, 2016, at 2:44 PM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote: >> >> >> >> Vivek Pandya >> >> >> On Wed, Mar 23, 2016 at 10:18 PM, Quentin Colombet <qcolombet at