similar to: Adding source location information to crash dumps

Cool this is better than I expected - I never thought about the YAML support. And the document reference is really very good. Thanks Francis, MartinO -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: 05 February 2018 21:43 To: Martin J. O'Riordan <MartinO at theheart.ie> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; Adam Nemet

I would like to be able to emit a list of functions by name and their fixed stack reservation size information, so that a programmer can gauge how much stack they are likely to need in tightly constrained embedded systems. Despite the rich number of options, the only option I can find that is even relatively close is: -warn-stack-size=<uint> Is there some existing way of getting this

Hi Martin, > On Feb 5, 2018, at 11:46 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would like to be able to emit a list of functions by name and their fixed stack reservation size information, so that a programmer can gauge how much stack they are likely to need in tightly constrained embedded systems. Despite the rich number of options, the

+llvm-dev at lists.llvm.org The impact should be small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one. 2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > Do they really allways put them into Release/bin or rather $<CONFIG>/bin? > > > > -- >

There are two unexpected failures in the check-all (this check-all runs with self-build-clang): Failing Tests (2): Clang Tools :: clang-tidy/clang-tidy-diff.cpp Clang Tools :: clang-tidy/file-filter.cpp Last log: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/340/steps/ninja%20check%202/logs/stdio From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Thursday, April

I sent out a patch for review. http://reviews.llvm.org/D10102 <http://reviews.llvm.org/D10102> -Chris > On May 28, 2015, at 9:48 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Thanks! > > 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>: > >> On May 28, 2015, at 8:37 AM, Yaron Keren

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise missed. All the best, MartinO -----Original Message----- From: Dibyendu Majumdar [mailto:mobile at

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) >

2015-05-03 21:02 GMT+09:00 Yaron Keren <yaron.keren at gmail.com>: > I now tried the extra tests and get the same failures: > > Clang Tools :: clang-tidy/clang-tidy-diff.cpp > Clang Tools :: clang-tidy/file-filter.cpp > > Takumi, I see you added requires:shell in r211831 and r220837. > > When using MSYS requires:shell is true but test fail, is it OK to >

Yes, it looks like passing ‘EnableVec’ and ‘EnableSLPVec’ to ‘Args.hasFlag’ should be replaced with ‘false’ and then it has the expected behaviour. MartinO From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Martin J. O'Riordan via cfe-dev Sent: 01 March 2018 18:02 To: 'Richard Smith' <richard at metafoo.co.uk> Cc: 'Clang Dev'

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. Code model, relocation model and and memory manager are whatever default for this - did not modify. The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function: A+1; A*B.t(); where A and B are