rjmccall wrote:
I agree with Eli. We should trust external record layout to the extent that it
generates a valid layout, but if it generates something with overlapping
fields, or that runs outside the claimed bounds of the type, we'll just end up
crashing in IRGen. I assume those things are
rjmccall wrote:
If LLVM wants to provide intrinsics that cover patterns that the frontend wants
to emit, that'd be great. The frontend will still have to make decisions about
e.g. whether to request Smith's algorithm, of course.
https://github.com/llvm/llvm-project/pull/78330
rjmccall wrote:
> > This is unrelated, but I wonder if we should proactively outline this
> > sequence; it's quite long.
>
> Not sure what you mean.
I mean that we could lazily emit a helper function like
`__clang_smiths_division_double` and call it instead of emitting like twenty
instructio
https://github.com/rjmccall approved this pull request.
LGTM as far as my requests; please wait for approval from the other reviewers.
This is unrelated, but I wonder if we should proactively outline this sequence;
it's quite long.
https://github.com/llvm/llvm-project/pull/78330
__
https://github.com/rjmccall commented:
It's bad that we don't have a IR test that breaks when you change the IR output
like this. Please add one.
https://github.com/llvm/llvm-project/pull/78330
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
@@ -978,7 +978,11 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const
BinOpInfo &Op) {
return EmitRangeReductionDiv(LHSr, LHSi, RHSr, RHSi);
else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited)
return EmitAlgebraicDiv(LHSr, LHSi, RHSr, RHSi);
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/78330
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
On Tue, Jan 7, 2020 at 3:18 PM Aaron Ballman wrote:
> It seems like GCC doesn't do good things when trying to link two
> functions with empty asm labels but Clang does seem to do something
> reasonable. I can't quite tell whether this is a case for a diagnostic
> or not. Note the generated assembl
On Tue, Jan 7, 2020 at 3:02 PM Aaron Ballman wrote:
> On Tue, Jan 7, 2020 at 2:57 PM John McCall via cfe-commits
> wrote:
> > On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator
> > wrote:
> > > Sorry to dredge up an old review, but I recently ran into a bug in this
> > > area and am n
On Tue, Jan 7, 2020 at 1:44 PM Aaron Ballman via Phabricator
wrote:
> aaron.ballman added inline comments.
>
>
>
> Comment at: cfe/trunk/lib/AST/Mangle.cpp:127
> +// do not add a "\01" prefix.
> +if (!ALA->getIsLiteralLabel() || ALA->getLabel().startswith("llvm.")) {
> +
10 matches
Mail list logo
