similar to: unusual use of getenv

Oh, right, this stuff. I guess the non-windows solution might've been a volatile read, for instance? So maybe not so much that the general machinery isn't needed, but that perhaps MSVC does something interesting with a volatile read or whatever other solution might've been used. Hmm, not sure why the whole file was added only when MSVC support was added - if it is a "static

Hi Michael On Tue Nov 10, 2020 at 1:29 AM GMT, Michael Kruse wrote: > Am Mo., 2. Nov. 2020 um 14:01 Uhr schrieb David Blaikie > <dblaikie at gmail.com>: > > Hmm, not sure why the whole file was added only when MSVC support was added - if it is a "static library object file selection" issue. Wouldn't that have turned up on other platforms before that moment? >

On Tue Jan 14, 2020 at 8:27 PM, Reid Kleckner wrote: > I don't think there's any technical reason for the current structure. Apparently [this](https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2019) is a thing. This results in the following delight happening on Visual Studio 2015: > fatal error C1091: compiler limit: string exceeds 65535 bytes in length So maybe

Hello I've been looking at the tables generated by `SequenceToOffsetTable::emit`, and notice that when the generated data are strings, the data is basically un-grep-able, and very tricky to read, as they are emitted as an array of comma-separated char-literal: extern const char HexagonInstrNameData[] = { /* 0 */ 'G', '_', 'F', 'L', 'O',

Hi all I wanted to do a quick build of a clean branch yesterday and noticed something surprising in the configure log: > -- No build type selected, default to Debug It appears that llvm's configuration forces Debug builds if the user does not specify the build type. https://github.com/llvm/llvm-project/blob/9218ff50f93085d0a16a974db28ca8f14bc66f64/llvm/CMakeLists.txt#L57-L60

On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > If you only want code addresses, why not use the CU's > low_pc/high_pc/ranges > - those are guaranteed to be only code addresses, I think? > In the common case, for most targets LLVM supports I think you're right, but for my case, regrettably, not. Because my target is a Harvard Architecture, any code address can have the

On Thu Mar 12, 2020 at 5:37 PM, David Blaikie wrote: > On Wed, Mar 11, 2020 at 8:09 AM Luke Drummond > <luke.drummond at codeplay.com> > wrote: > > > On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > > > If you only want code addresses, why not use the CU's > > > low_pc/high_pc/ranges > > > - those are guaranteed to be only code

Hello I've been looking at a debuginfo issue on an out-of-tree target which uses DWARF aranges. The problem is that aranges are generated for both data and code objects, and the debugger gets confused when program addresses overlap data addresses. The target is a Harvard Architecture CPU, so the appearance of overlapping address ranges is not in itself a bug as they reside in different

On Tue Nov 17, 2020 at 6:37 PM GMT, Min-Yih Hsu wrote: > Just trying to understand: Are you suggesting a way to have a “-O0” > build without all the debug information? > Exactly.

Hi All, I have a question about TableGen RegisterClass definition. I need to map different size of MVTs into a register class as below. def TestReg : RegisterClass<"Test", [v8i32, v4i32], ...> When I look at TableGen and CodeGen, it looks the types are used as following: 1. MCRegisterClass's RegSize and Alignment 2. SpillSize in TableGen 3. Type constraint for instruction

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be

On Wed, 15 Jan 2020, Reid Kleckner via llvm-dev wrote: > On Wed, Jan 15, 2020 at 11:14 AM Luke Drummond <luke.drummond at codeplay.com> > wrote: > On Wed Jan 15, 2020 at 6:58 PM, Reid Kleckner wrote: > > Does the same limitation exist in VS 2017? I think that's our > support > > floor > > these days: >

Hi, I found that prologue_end markers where badly placed in my test, and applied https://reviews.llvm.org/D41762 in the hope that it would fix it (I'm on 4.0.1). However, this fix doesn't work for VLIW architectures. At this point we're iterating over bundles, not MachineInstructions, and the FrameSetup flag is set on MachineInstructions, not bundles. If bundling happens in the

I’ve encountered this kind of architecture before, a long time ago (academically). In a flat-address-space machine such as X64, there is still an instruction/data distinction, but usually only down at the level of I-cache versus D-cache (instruction fetch versus data fetch). A Harvard architecture machine exposes that to the programmer, which effectively doubles the available address space.

Hello everyone, Consider we have this following set of code: int foo() { int a,b; a = __builtin_XX(0x11); b = __builtin_XX(0x11); return a+b; } The problem currently is that LLVM eliminated the second call and copied the result from the first call into a new set of registers. Is there is a way to force LLVM to generate two explicit calls to a builtin function. The builtin takes in an integer

Yeah, that's one I'd be in favor of fixing, if it's still the case. On Tue, Nov 17, 2020 at 5:38 PM Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm curious how much of this is due to not using LLD? Last I checked, using ld.bfd instead of LLD (or gold) was one of my major build time issues, and somehow our default configuration would use ld.bfd. >

Hi folks, Not sure if this is the right mailing list target, but I'm trying out the new LLVM 7.0 packages found at http://apt.llvm.org by porting over an existing LLVM 6.0 project of ours to the new version. In doing so, I found that the executable always segfaulted at the same spot with no explanation: 0x0000000000fefe33 in

Hi, anyone know anything about copy propagation? Matthias, I see this was your code originally? Was there some assumptions you made? I'm hitting an assertion in MachineCopyPropagation::isNopCopy: if (Src == PreviousSrc) { assert(Def == PreviousDef); return true; } This code compares two COPY instruction to see whether they are effectively "the same". The assert assumes

I'm not across most of this debug info stuff but I'll stomp in here to confirm that AVR is a Harvard architecture, with separate addressing for the data and program buses via specialized instructions which will load from either one, or the other, but never both. It makes sense that this particular problem would also affect AVR - the backend does have some issues with debug info

On Wed Jan 15, 2020 at 6:58 PM, Reid Kleckner wrote: > Does the same limitation exist in VS 2017? I think that's our support > floor > these days: > https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library > It appears that all releases including the latest 2019 are affected. > > One *could* make the tablegen behavior conditional on the