labath wrote:
> single interface to traverse the AST tree:
That's the part that would change in this setup. Instead of one API, we'd have
two: `EvaluateValueNode()` and `EvaluateScalarNode()`, and we'd have two node
hierarchies: ValueNode and ScalarNode. MemberOfNode would be a ValueNode
beca
kuilpd wrote:
> We can definitely add functions to covert (directly) between Scalars and
> ValueObjects (in fact, I think the only reason that the APInt overloads
> currently exists is because of the initial attempt to upstream the DIL
> implementation).
Ah, I didn't know that, I think I joi
labath wrote:
> 1. Constant wrapping/unwrapping of Scalar(APInt). For literals, it goes:
> parse as APInt -> wrap to Scalar to create a node -> unwrap APInt to create
> ValueObjectSP -> wrap to Scalar to use arithmetic operation -> unwrap APInt
> to create ValueObjectSP. Not sure if it's a pro
kuilpd wrote:
> say that values retain their width and signedness, but then get converted
> into the wider width using C-like rules. We already have this implemented
> inside the Scalar class (which wraps APInt), so this would be best in terms
> of code reuse, and it would produce few surprise
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/147064
>From cf1f908360399ac51770d9fb7e1dac03eceab0e9 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 3 Jul 2025 19:34:17 +0500
Subject: [PATCH 1/2] [LLDB] *WIP* Add scalar literal node and binary addition
---
l
labath wrote:
> > but I can also imagine doing something like python's "arbitrary width"
> > integers.
>
> Isn't this basically `llvm::APInt` class?
Sort of, but not quite. APInt has an arbitrary but fixed width. Python integers
scale their width dynamically to fit the result (so they sort of
kuilpd wrote:
> but I can also imagine doing something like python's "arbitrary width"
> integers.
Isn't this basically `llvm::APInt` class? We could just disregard every
integer's type, add their values as `APInt` and return the result with a
maximum width integer type. I kind of like this p
labath wrote:
Personally, I'd be fine with saying that anytime we start doing arithmetic on
something (maybe, whenever we do a lvalue-to-rvalue conversion?) we switch to a
"DIL" type system. We could make that "type system" work mostly like C, but I
can also imagine doing something like python
kuilpd wrote:
> We could, but I'm not sure if that's the most important question right now.
> The whole BasicType concept is very C-like. There is no "unsigned long long"
> basic type in swift (or pretty much any other language). While you could say
> that the function returns the langauge's e
labath wrote:
We could, but I'm not sure if that's the most important question right now. The
whole BasicType concept is very C-like. There is no "unsigned long long" basic
type in swift (or pretty much any other language). While you could say that the
function returns the langauge's equivalen
augusto2112 wrote:
> Here is the problem with types: initial scalar literal type, all the type
> promotions and conversions are done using `lldb::BasicType` enumeration
> types, and later converted to `CompilerType` using the `TypeSystem`. In C++,
> this works perfectly well, because in
> [`T
kuilpd wrote:
@labath @cmtice @jimingham @asl
This is a draft with some potential changes I'd like to discuss regarding how
to handle the type system of constant literals.
I'm also trying to demonstrate how they interact further with other values in a
binary addition node. A lot of the code is
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ilia Kuklin (kuilpd)
Changes
A draft to discuss scalar literal node implementation
---
Patch is 26.08 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/147064.diff
8 Files Affected:
- (modified)
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/147064
A draft to discuss scalar literal node implementation
>From cf1f908360399ac51770d9fb7e1dac03eceab0e9 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 3 Jul 2025 19:34:17 +0500
Subject: [PATCH] [LLDB] *WIP*
14 matches
Mail list logo
