similar to: [LLVMdev] measuring the stack size

On Apr 17, 2008, at 13:00, Jonathan S. Shapiro wrote: > On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > >> On Thu, 17 Apr 2008, guan mailist wrote: >> >>> Does anyone have good ideas to dynamically measure the stack size >>> of a >>> program by using LLVM. I am trying to add some new intrinsic >>> functions after each

> Date: Thu, 17 Apr 2008 13:54:12 -0400 > From: "Jonathan S. Shapiro" <shap at eros-os.com> > > > > > The GC infrastructure exposes this information in a framework suitable > > for emitting metadata tables from a compiler plugin, if your interest > > lies in that direction. > > That too, but my immediate interest was computing an upper bound

On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > On Thu, 17 Apr 2008, guan mailist wrote: > > Does anyone have good ideas to dynamically measure the stack size of a > > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do

On Thu, 17 Apr 2008, guan mailist wrote: > Does anyone have good ideas to dynamically measure the stack size of a > program by using LLVM. > I am trying to add some new intrinsic functions after each "alloca" in > bitcode. Is it a good way to do it? > Any existing tools can help me to do so? Depending on how much precision you need, you could use the llvm.frameaddress

Dear All, Does anyone have good ideas to dynamically measure the stack size of a program by using LLVM. I am trying to add some new intrinsic functions after each "alloca" in bitcode. Is it a good way to do it? Any existing tools can help me to do so? Any help will be deeply appreciated. Thank you, GUanhua -------------- next part -------------- An HTML attachment was scrubbed...

On Apr 4, 2008, at 11:58 AM, Jonathan S. Shapiro wrote: > In general, it is not possible to know jitted code size without > emitting. You can suppress the actual write of the instructions > themselves, but you have to do all of the work prior to that point. That's not true. llvm targets which support JIT have all the information necessary to calculate the size of every

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: >> On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >>>> >>>> i64 should be big enough for this. Just use i64. >>> >>> On a 32-bit platform, doesn't one want to use i32? >> >> Why? What is wrong with i64? > > On its face,

On Wed, 2008-05-14 at 13:26 -0400, David Vandevoorde wrote: > On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > >> Jonathan S. Shapiro wrote:- > >>> Is there a requirement somewhere in the C *Language* Specification > >>> that > >>> ties all of this together in the required

Hi All, Regarding cycle measurements for ARM/NEON, ARM no longer provide cycle accurate simulators. The method we use is to to make measurements on hardware via the PMU unit on the core itself. Note that if your running under Linux you may be 'allowed' to access the PMU directly but can access via it system calls. Typically you will need to make a series of measurements and average them.

On Fri, 4 Apr 2008, Jonathan S. Shapiro wrote: > Evan: please explain how span-dependent branches are resolved in your > method. You don't need to compute the bits that will be emitted, but you > do need to compute the length of those bits. In most real > implementations, the two steps are therefore inseparable. I think the important point here is that llvm explicitly represent

On Fri, 2008-04-04 at 12:15 -0700, Evan Cheng wrote: > On Apr 4, 2008, at 11:58 AM, Jonathan S. Shapiro wrote: > > > In general, it is not possible to know jitted code size without > > emitting. You can suppress the actual write of the instructions > > themselves, but you have to do all of the work prior to that point. > > That's not true. llvm targets which

On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: >> Jonathan S. Shapiro wrote:- >>> Is there a requirement somewhere in the C *Language* Specification >>> that >>> ties all of this together in the required way? >> >> Reserved identifiers and header inclusion. >> >> Neil.

I am using mpop to fetch mail from my service provider (who use dovecot). I use dovecot to hold all my mail on a local slackware server, with sieve filters, based on 'List-Id', directing mailist postings to their own folders. I use thunderbird to read my mail on an ubuntu desktop. When I receive a reply to a posting I make to a mailist (such as this one), replies I receive are

In general, it is not possible to know jitted code size without emitting. You can suppress the actual write of the instructions themselves, but you have to do all of the work prior to that point. The reason is that on many architectures there are span-dependent branches. The final instruction size depends on the branch span. The span depends on the code size, and the code size depends on the

On Apr 30, 2008, at 5:20 PM, Jonathan S. Shapiro wrote: > On Wed, 2008-04-30 at 15:25 -0400, David Vandevoorde wrote: >> On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote: >>> Daveed: >>> >>> Perhaps I am looking at the wrong version of the specification. >>> Section >>> 5.1.2.3 appears to refer to objects having volatile-qualified type.

On Thu, Oct 01, 2020 at 04:01:29PM -0400, mailist wrote: > The Ubuntu-derived distros are much better suited to desktop. I run several > of them, as well as > CentOS 7 and 8. Ubuntu, Kubuntu (Ubuntu with KDE), Lubuntu, Debian, PopOS, > and Zorin. They all use systemd. If you're running CentOS 6 to avoid that, you're out of luck. -- Jonathan Billings <billings at

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >> On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote: >> Querying TargetData only works if you know the size of the pointer. :) > In the end, the use case that concerns me is things like character > vectors, because of the fact that the index spans depend on the address > space size. I'm not clear whether it is a goal

On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > Jonathan S. Shapiro wrote:- > > Is there a requirement somewhere in the C *Language* Specification that > > ties all of this together in the required way? > > Reserved identifiers and header inclusion. > > Neil. What section of the C standard do I need to refresh myself on here?

Hi, I've been doing an experiment, measuring the dead-zone-diameters of bacteria, when they've been grown with paper diffusion disks of antimicrobial. There are two groups, or treatments - one is bacteria that have been cultured in said antimicrobial for the past year, the other group is of the same species, but lab stock and has not gone had any prior contact with the antimicrobial.

On Thursday 01 May 2008 19:14, Jonathan S. Shapiro wrote: > On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote: > > On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > > > > > If LLVM is able to eliminate all users of the malloc assuming the > > > malloc succeeded (as in this case), then it is safe to assume the malloc > > > returned success. >