search for: qoi

...art > > > Is it inherent to the infrastructure, i.e. using metadata instead of first > class IR construct or is it just a “quality of implementation” issue? > > Not to derail this conversation: IMHO, At some point there is no real difference :) Because otherwise, everything is a QOI issue. IE if it's super tricky to get metadata that works well and works right, doesn't get lost, etc, and that's inherent to using metadata, that to me is not a QOI issue. So could it be done with metadata? Probably? But at the same time, if it had been done with more first class co...

...ld make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ They are all TypePrinter failures like this one? If so I would say we should not block on it since it is a small QOI issue. On the other hand Reid says it should be an easy fix, so we can wait a bit. Cheers, Rafael

...ns that the debugger either says "your variable is certainly > here" or it says "I don't know", it never says "your variable might be > here". I agree. > 2. Based on #1, it is preferable for all optimizations to update debug > info. This improves the QoI of the debugging experience when the > optimizations are enabled. However, based on #1, if they can't or > haven't been updated yet, they should just discard it. What about possibility of skipping the optimization if it can not update debug info successfully ? When, I presented...

...data instead >> of first class IR construct or is it just a “quality of >> implementation” issue? >> >> >> Not to derail this conversation: >> >> IMHO, At some point there is no real difference :) >> >> Because otherwise, everything is a QOI issue. >> >> IE if it's super tricky to get metadata that works well and works >> right, doesn't get lost, etc, and that's inherent to using metadata, >> that to me is not a QOI issue. >> >> So could it be done with metadata? Probably? >> But...

A question of preference came up in https://reviews.llvm.org/D83588 <https://reviews.llvm.org/D83588> as to whether we ought to prefer emitting TableGen error messages with all of the information in a single diagnostic, or whether it makes sense to split things in an error+note style as seen in many clang diagnostics. TableGen doesn’t use a DiagnosticsEngine, so the concept of a fatal note

...rote: > > > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for > production use at least for x86-64 (and probably for AArch64 and MIPS). > > We’re now using it with all three architectures on FreeBSD (though only > the n64 ABI for MIPS) and will file bugs. One QoI issue that’s bitten us a > couple of times is that the versions of clang and lld must match for LTO to > work. If they don’t, we don’t get an error message, we simply get programs > that segfault on startup. I’m a bit surprised that reading the bitcode > doesn’t return an error that L...

...ools\clang\test\SemaCXX\virtual-override.cpp Line 288: virtual function 'foo' has different calling convention attributes ('void ()') than the function it overrides (which has calling convention 'void () __attribute__((thiscall))') 2 errors generated. I guess this is also a QOI problem, but the diagnostic here gets pretty misleading. - Hans

...al-override.cpp Line > 288: virtual function 'foo' has different calling convention > attributes ('void ()') than the function it overrides (which has > calling convention 'void () __attribute__((thiscall))') > 2 errors generated. > > I guess this is also a QOI problem, but the diagnostic here gets > pretty misleading. Yes, I guess this a case of the error being pedantically correct. We should suppress the second error. Cheers, Rafael

On Jul 23, 2008, at 10:44 AM, Devang Patel wrote: >> 2. Based on #1, it is preferable for all optimizations to update >> debug >> info. This improves the QoI of the debugging experience when the >> optimizations are enabled. However, based on #1, if they can't or >> haven't been updated yet, they should just discard it. > > What about possibility of skipping the optimization if it can not > update debug info successfully ?...

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

On Mon, Mar 19, 2012 at 5:24 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Mon, Mar 19, 2012 at 4:52 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Mon, Mar 19, 2012 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> > > wrote: > >> > >> Given that, I'm not sure I really see the issue with just > >>

.../foreign there, but perhaps something that makes sense adding. >> >> Is there any precedence here for other internal llvm tooling (outside of clang)? What’s the general consensus here? > > I think it makes a lot of sense to add this to TableGen. It is a widely used tool and the QoI for its error messages could use a lot of improvement! There is a lot of room from improvement in several details of TableGen. However, methinks that changes towards such a goal shouldn't be sneaked in small doses. Then it just adds more inconsistent error reporting to an already inconsisten...

...The unused argument > warning is the only warning which can catch this at the moment. In cases where we can easily detect a bad argument situation, I believe part of Chad's proposal should be that we implement specific warnings for those cases. Among other things, this greatly increases the QOI of those warnings. The "option-for-non-active-target" diagnostic seems like one we definitely would want to implement (and should be straightforward using option groups I think. - Daniel > > -Eli

On Mon, Mar 19, 2012 at 4:52 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Mar 19, 2012 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> Given that, I'm not sure I really see the issue with just >> special-casing any store where the value stored is a pointer to a >> global... but it could be argued either way, I

On 9 Feb 2017, at 08:41, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > What isn’t clear to me still is : why shouldn't this be transitive? > In the example you’re showing, for a caller of f() in bar, what is the advantage of knowing that f() is nounwind if it an

...re, i.e. using metadata instead of first >>> class IR construct or is it just a “quality of implementation” issue? >> >> Not to derail this conversation: >> >> IMHO, At some point there is no real difference :) >> >> Because otherwise, everything is a QOI issue. >> >> IE if it's super tricky to get metadata that works well and works right, >> doesn't get lost, etc, and that's inherent to using metadata, that to me is >> not a QOI issue. >> >> So could it be done with metadata? Probably? >> But...

...aving correctly here. I don't know whether libc++'s implementation is valid (I don't know under what circumstances the library can use constructs which could depend on the completeness of user-provided types) but I suspect it is not, and even if it were, we'd want to allow this as a QoI issue. Here's a fix (first change: avoid overloaded 'operator,', second change: avoid ADL for __is_assignable_test): --- type_traits (revision 164877) +++ type_traits (working copy) @@ -1187,10 +1187,15 @@ #endif // _LIBCPP_HAS_NO_VARIADICS +template <class _Fst, class _Snd>...

I'm a new LLVM developer contributing patches for the AVR platform and I'm trying to understand which parts of the code base are malfunctioning in my case. This LLVM IR... define hidden i32 @setServoAngle3(i32) local_unnamed_addr { entry: %1 = call i32 @myExternalFunction1(i32 %0, i32 119) ret i32 %1 } declare i32 @myExternalFunction1(i32, i32) Is being lowered to this assembly

Hi Jeff, Do you know if anything came of this? I understand we may need to seek clarification to get a formal answer, particularly with respect to C, but it seems pretty clear to me that this is a significant QoI issue, both for C and CL. LLVM is effectively hoisting a load above a thread-join. This may or may not technically allowed in C, but it seems generally undesirable, and it’s extremely undesirable in CL where these kinds of thread joins are a fundamental of the programming model. —Owen On Aug 6...

...3: debug: exiting worker thread memory.3 > So the immediate NBD_CMD_DISC is reasonable, implying that the client flagged one of the ways you could have violated protocol (but whether qemu should just hang up, or should just ignore that particular reply but still keep the connection alive, is a QoI question for qemu). > and qemu-img exits with code 1, but there is no message printed. > (You can use --run '... || echo FAIL' if you don't believe that > qemu-img is exiting with a failure.) > > While preparing this email I noticed that v3.1.0 printed an > error mes...