Displaying 20 results from an estimated 53 matches for "dyn_cast_or_null".
2010 Jul 22
2
[LLVMdev] Casting.h illness
On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote:
> Am 22.07.2010 um 00:21 schrieb Chris Lattner:
>
>> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
>>> Is this a recommended approach/good style/good idea to use
>>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other
>>> is and cast functions).
>>
>> We generally don't want auto-dereference. There is some special magic for unwrapping Uses etc though. Is this what you're in contact with Gabor?
>>
>> -Chr...
2010 Jul 21
2
[LLVMdev] Casting.h illness
On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
> Is this a recommended approach/good style/good idea to use
> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other
> is and cast functions).
We generally don't want auto-dereference. There is some special magic for unwrapping Uses etc though. Is this what you're in contact with Gabor?
-Chris
>
> Eugene
>
> On Wed, Jul...
2010 Jul 22
0
[LLVMdev] Casting.h illness
...Chris Lattner:
>
> On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote:
>
>> Am 22.07.2010 um 00:21 schrieb Chris Lattner:
>>
>>> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
>>>> Is this a recommended approach/good style/good idea to use
>>>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And
>>>> other
>>>> is and cast functions).
>>>
>>> We generally don't want auto-dereference. There is some special
>>> magic for unwrapping Uses etc though. Is this what you're i...
2010 Jul 21
2
[LLVMdev] Casting.h illness
Hi all,
at the moment I am trying to fix an unnecessary iterator dereferencing
in Casting.h and am uncovering several ugly things.
For example, look at this code:
> // dyn_cast_or_null<X> - Functionally identical to dyn_cast, except that a null
> // value is accepted.
> //
> template <class X, class Y>
> inline typename cast_retty<X, Y>::ret_type dyn_cast_or_null(const Y &Val) {
> return (Val && isa<X>(Val)) ? cast<X, Y>(...
2010 Jul 21
0
[LLVMdev] Casting.h illness
Is this a recommended approach/good style/good idea to use
dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other
is and cast functions).
Eugene
On Wed, Jul 21, 2010 at 12:42 PM, Gabor Greif <gabor at mac.com> wrote:
> Hi all,
>
> at the moment I am trying to fix an unnecessary iterator dereferencing
> in Casting.h and am unco...
2019 Apr 05
2
[RFC] Should we add isa_or_null<>?
...Agreed that the new isa_or_null style is better. Just wanted mention the
> other style so we know we should migrate those to the new one.
>
I have a checker under review that could be enhanced to do that -- though
it currently replaces `X->foo() && isa<Y>(X->foo())` with
`dyn_cast_or_null<Y>(X->foo())`.
Please see: https://reviews.llvm.org/D59802
thanks...
don
>
> ~Craig
>
>
> On Thu, Apr 4, 2019 at 4:37 PM Don Hinton <hintonda at gmail.com> wrote:
>
>> On Thu, Apr 4, 2019 at 6:29 PM Craig Topper <craig.topper at gmail.com>
>> w...
2019 Apr 04
2
[RFC] Should we add isa_or_null<>?
On Thu, Apr 4, 2019 at 6:29 PM Craig Topper <craig.topper at gmail.com> wrote:
> There are a handful of places in LLVM that dosomething like if
> (dyn_cast_or_null<UndefValue>(P->hasConstantValue()))
>
Yes, I've seen those, but while working on a new checker, I was advised
that replacing `X && isa<Y>(X)` with `dyn_cast_or_null<Y>(X)` was
suboptimal, and it was suggested something like a `isa_or_null` style
operator would b...
2010 Jul 22
0
[LLVMdev] Casting.h illness
Am 22.07.2010 um 00:21 schrieb Chris Lattner:
> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
>> Is this a recommended approach/good style/good idea to use
>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other
>> is and cast functions).
>
> We generally don't want auto-dereference. There is some special
> magic for unwrapping Uses etc though. Is this what you're in
> contact with Gabor?
>
> -Chris
>...
2012 Feb 09
2
[LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...
...; +++ PatternMatch.h (revision 149912)
> @@ -98,13 +98,6 @@
> Res = &CI->getValue();
> return true;
> }
> - // FIXME: Remove this.
> - if (ConstantVector *CV = dyn_cast<ConstantVector>(V))
> - if (ConstantInt *CI =
> - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) {
> - Res = &CI->getValue();
> - return true;
> - }
> if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V))
> if (ConstantInt *CI =
> dyn_cast_or_null<ConstantInt>(CV-&...
2019 Apr 04
2
[RFC] Should we add isa_or_null<>?
...t;(var)) {
> > > ...
> > > }
> > >
> > > at least according to what "isa_or_null" conveys to me.
> >
> > This is the same convention used by the existing "_or_null" varieties,
> > i.e., "cast_or_null" and "dyn_cast_or_null". They accept a null and
> > propagate it. In the "isa" case, it would accept a null and propagate
> > it as false.
>
> isa<> is very different from *cast<>. *cast<> gives you a pointer back,
> which may be null. isa<> is precondition...
2012 Feb 10
0
[LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...
...vision 149912)
>> @@ -98,13 +98,6 @@
>> Res = &CI->getValue();
>> return true;
>> }
>> - // FIXME: Remove this.
>> - if (ConstantVector *CV = dyn_cast<ConstantVector>(V))
>> - if (ConstantInt *CI =
>> - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) {
>> - Res = &CI->getValue();
>> - return true;
>> - }
>> if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V))
>> if (ConstantInt *CI =
>> dyn_cast_or_null<...
2012 Feb 10
1
[LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...
...,13 +98,6 @@
>>> Res =&CI->getValue();
>>> return true;
>>> }
>>> - // FIXME: Remove this.
>>> - if (ConstantVector *CV = dyn_cast<ConstantVector>(V))
>>> - if (ConstantInt *CI =
>>> - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) {
>>> - Res =&CI->getValue();
>>> - return true;
>>> - }
>>> if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V))
>>> if (ConstantInt *CI =
>>>...
2014 Oct 18
2
[LLVMdev] Dereferencing NULL pointer in IndVarSimplify.cpp?
Hi,
Here is the code in IndVarSimplify.cpp.
SmallVector<WeakVH, 16> DeadInsts;
while (!DeadInsts.empty())
if (Instruction *Inst =
dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val()))
RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI);
Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL
pointer, the expression, &*DeadInsts.pop_back_val(), could be &*NULL.
Then NULL pointer is dereferenced here.
I...
2015 Aug 21
2
Canonical representation for empty lists in debug info metadata
...a few test cases that crash at head, without my
debugging assertions for accessing pointee types.
One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll
Its retainedTypes metadata points to a metadata array of a single null
element.
This crashes the dyn_cast (because it's not a dyn_cast_or_null)
Verifier.cpp:3785
Do you have a preferred/canonical representation intended in this case - an
extant, but zero-length list, or no list at all? I tend to prefer no list
at all, just because it simplifies reading of the debug info. Rather than
seeing a "retainedTypes" property, following...
2019 May 05
3
[RFC] Should we add isa_or_null<>?
+1 on not adding the new API
On Sat, May 4, 2019, 11:51 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1, if we're voting. I don't think it adds to the readability of code
> for me personally.
>
> On Sat, May 4, 2019 at 11:47 AM Chandler Carruth via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On Mon, Apr 29, 2019,
2019 Apr 04
2
[RFC] Should we add isa_or_null<>?
...t; }
>
> is not the same as:
>
> if (isa_or_null<T>(var)) {
> ...
> }
>
> at least according to what "isa_or_null" conveys to me.
>
This is the same convention used by the existing "_or_null" varieties,
i.e., "cast_or_null" and "dyn_cast_or_null". They accept a null and
propagate it. In the "isa" case, it would accept a null and propagate it
as false.
>
> not_null_and_isa<T> would seem a better fit, or maybe exists_and_isa<T>.
>
> That said, I'm not sure sure we need a special API for this....
2015 Jun 17
2
[LLVMdev] Inline hint for methods defined in-class
...they are defined in the class body. I tried
the following patch, which I believe handles the in-class definition
case:
--- a/lib/CodeGen/CodeGenFunction.cpp
+++ b/lib/CodeGen/CodeGenFunction.cpp
@@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD,
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) {
if (!CGM.getCodeGenOpts().NoInline) {
for (auto RI : FD->redecls())
- if (RI->isInlineSpecified()) {
+ if (RI->isInlined()) {
Fn->addFnAttr(llvm::Attribute::InlineHint);
break;
}
I tried this on C++ benc...
2008 Dec 31
1
[LLVMdev] llvm ocaml bindings
...asic blocks in a functions [iter_blocks]
> * instructions in a block [iter_instrs]
>
> The other things that i'd like are to know what kind of
> instruction a given instruction was.
Hi Ranjit,
There are recently aded C bindings for the "isa<>" template (actually,
dyn_cast_or_null<>), which is usually the preferred manner to access
the type ID. There are no corresponding ocaml bindings yet. I think
this is the most important missing feature for what you've described;
most of the instruction properties have getters and setters.
Re exposing the type ID as an O...
2011 Nov 17
1
[LLVMdev] How to get ELF section virtual starting address from MCSymbolRefExpr?
...ection it belongs, in this case .text, but it could be any section.
I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr:
int Kind = Value->getKind();
if (Kind == MCExpr::SymbolRef) {
const MCSymbol &Sym = SRE->getSymbol();
const MCSectionELF = dyn_cast_or_null<MCSectionELF>(Sym.getSection());
}
But can't see how to get the virtual address of the section. This is odd since I would have expected methods for accessing every part of the ELF section header entry.
How does one get the virtual address (sh_addr in ELF) starting from a MCSymbolRefEx...
2013 Jul 22
0
[LLVMdev] Inverse of ConstantFP::get and similar functions?
----- Original Message -----
> Hi,
>
> I noticed that ConstantFP::get automatically returns the
> appropriately
> types Constant depending on the LLVM type passed in (i.e. if called
> with a vector, it returns a splat vector with the given constant).
>
> Is there any simple way to do the inverse of this function? i.e.,
> given a llvm::Value, check whether it is either